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32 Bringing Engineering 
Discipline to Game Development 


Tired of the chaos of the typical game development 
cycle? Kesmai Studios applied traditional develop- 
ment methodologies to its game projects and now 
deadlines come and go like a soft breeze on the water. 
BY GORDON WALTON 
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a6 DEER HUNTER’s Three-Month oo See 
Development Cycle 


Hardcore developers may scoff, but DEER HUNTER cost 
pennies to develop, used only a skeletal staff, and sold 
tens of thousands of copies at $20 apiece. Read about 
Sunstorm’s no-nonsense approach to task allocation 
and scheduling. 

BY JAMES BOER 


se An Introduction to Sound Filtering 


Understanding the basic structure of sine waves will 
help you pull off some intricate audio effects. 
BY JONATHAN BLOW 


58 Postmortem: 
Goldtree's DEAD RECKONING 


Emphasizing ambitious design and past challenges and , 

successes, Goldtree has succeeded in making the move aici apes Smt 

from a small start-up to a promising hit-producer. 5 Says You! 
BY LUKE AHEARN = 
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Graphic Content BY JEFF LANDER 
Mighty Morphing Mesh Machine 
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Artist’s View BY MEL GUYMON 


Sen Senn Want eo bake Cansols Gand COVER: "Team Drakan" from the game DRAKAN, a real-time 3D 
30); : J ; 


action adventure currently under development at Surreal Software 


(published by Psygnosis). Character designs, models, and textur- 
Hard Targets BY OMID RAHMAT f , iis iid aes ie ae te 
ing were done by Hugh Jamieson using 3D Studio MAX and anc 

Trends in the Graphics Board Market . —— - a 


the Riot Engine Modeller. Scene composition and character poses 


were done in Softimage 3.8 by Mel Guymon, Heron Prior, and 
Soapbox BY TERRY BRATCHER ft a (eee ee eae. 
Louise Smith. For more information about DRAKAN, go to 
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The Game Developer’s Resource Center 
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Ditch the Death March 


t the conclusion of World 
War II, Japan was nowhere 
near the industrial power- 
shouse that it is today. The 
management of Japanese companies 
was almost feudal in nature: plant man- 
agers were practically overlords, and 
workers were viewed as serfs. One of the 
people who helped turn Japan around 
in the ‘SOs was American management 
consultant Dr. Edwards Deming. 

Deming’s lesson to managers in 
Japan and America was fairly simple. In 
a nutshell, he said that managers’ infat- 
uation with short-term thinking, merit 
systems, quotas, management by objec- 
tives (MBO), and so on, was all wrong. 
Instead, he said, special importance 
should be placed on the process of pro- 
duction, not the end product itself. If 
the production process was good, quali- 
ty products would naturally flow from 
the company. 

It worked. Take Toyota, for instance. 
The company’s initial experience sell- 
ing cars in America was disastrous; the 
Toyota Toyopet was a stark, underpow- 
ered vehicle that sold poorly. Later, 
armed with production processes based 
on the work of Deming, Walter 
Shewhart, and others, Toyota went 
back to the drawing board (literally). 
Using product testing, customer feed- 
back, and studying the lessons of the 
then-successful Volkswagen Beetle, 
Toyota came up with the Corolla. This 
car sold well, and thanks to continued 
use of process improvement method- 
ologies, Toyota’s engineers were able to 
improve the product each year. 

Of course, games are not pieced 
together on an assembly line. But many 
of Deming’s lessons still hold true for 
game developers. In this month’s cover 
feature (“Bringing Engineering 
Discipline to Game Development”, 
page 37), Kesmai Studios Manager 
Gordon Walton explains how better 
development processes helped his com- 
pany, and many of these experiences 
jibe with Deming’s lessons. Many of 
you worked your tails off to complete 
projects in time for Christmas, so 
you're probably receptive to better 
methods of managing projects. Wasn’t 
that death march fun? 
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As Walton explains in his article, 
Kesmai (like practically every game 
development company) experienced 
intense pressure to complete a number 
of games in time to guarantee their 
delivery to stores by Christmas. The 
burnout and frustration that this used 
to cause his teams prompted the com- 
pany to find ways to gain better control 
of projects. And while Walton stresses 
that Kesmai’s developers still encounter 
the occasional “crunch period,” adopt- 
ing formalized development standards 
and procedures for their projects has 
given everyone more confidence in esti- 
mating work duration, resulted in fewer 
bugs in their games, and made the 
process of developing a title more 
rewarding for everyone. Without a 
doubt, Walton’s article provides the 
most detailed accounting of process 
improvement by a game development 
studio that I’ve seen. 


“Sundance” Postscript 


In the wake of my September editorial 
(“Where’s Our Sundance?”), I received 
quite a number of letters from readers 
about various events that either already 
exist, or that are in the planning stages. 
First, Brooke Boynton of P.F. Magic 
reminded me that New Media maga- 
zine’s Invision Awards (http://www. 
invisionawards.com) honor a wide 
range of multimedia and web products, 
including games. Second, it appears that 
Milia Games (http://www.milia.com), 
the French conference for interactive 
entertainment, will host a “New Talent 
Pavilion” at its upcoming event in 
February. Finally, the Game Developers 
Conference (http://www.gdconf.com) is 
launching the “GDC Independent 
Game Festival” at its show in San Jose, 
Calif., this March. In the interest of full 
disclosure, I must remind everyone that 
the GDC and Game Developer magazine 
are owned by the same company. 
Which, of course, made it very easy for 
me to twist their arms. 


Mv he. 
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Solving the Orc Problem 


just read through the October 1998 
issue of Game Developer (all of us 
here at GameFX... err THQ... fight over 
the latest issue of Game Developer every 

month), including Swen Vincke’s 
interesting article, “The Orc Problem.” 
While the article was informative, 
there are, in fact, well-known and bet- 
ter ways to solve this exact : 
problem. This is a clas: 
resource allocation 
problem that : 
can be 

solved quick- 

ly and easily 
using a tech- 
nique known as 
dynamic program- 
ming. This algorithm — e 
isalso sometimes known 


as Viterbi decoding or Hidden Markov 


model decoding. These algorithms 
were developed in the 1960s to assign 
nuclear missiles to targets. 

You want to avoid greedy solutions 
for simple fitness functions if they are 
not the optimal choice. If you have a 
simple fitness function that only takes 
into account the two units involved, 
(that is, if unit a attacks unit b you get 
one score, and then if you also attack b 
with another unit c, the score for 
attacking b with c is not affected by 
the fact that it has already been 
attacked by a), then the “greedy” solu- 
tion is optimal. That is, get each of 
your units to attack the unit that it 
gets the highest score for attacking. 
Because the pairwise evaluations are 
independent, you need to compare 
each of your own units against each 
enemy unit one time each. If you have 
n of your own units and m enemy 
units, this can be calculated in time 
that scales as m*n. In an eight on eight 
fight, this is 64 pairwise evaluations. In 
a battlefield game where the units are 
usually spread out and the scoring 
function takes into account the dis- 
tance between the units involved, this 
method can work pretty well. This is 
probably less expensive than a single 
call to Vinke’s fitness function. But the 
trade-off is that it won’t give you as 
accurate an answer. 

Dynamic programming is the solu- 
tion for the harder fitness functions. If 
you have a fitness function where the 
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score for attacking unit a with unit b 
depends on what other units are 
attacking it (or the configuration of 
units as a whole ) then you have to use 
an algorithm that’s just a little bit 
smarter. The trick here is that if I have 
an algorithm, 

and 







Well let you talk. E-mail us at 
gdmag@mfi.com. Or write to Game 
Developer, 600 Harrison Street, San 
Francisco, CA 94107. 




















if | 
give it an 

' optimal solution for a given 
set of units and then add one 
ore unit to my team, the 
algorithm will give me a new 
optimal solution. Then, given 
any set of units, I just start by 


: a finding the optimal solution given 


one unit and then I keep adding units 
one by one and finding a new optimal 
solution, given the old optimal solu- 
tion as input. 

Here’s how to execute that task. 
First, | make a matrix with enemy 
units indexing the rows, and with my 
own units indexing the columns. Then 
I start with column zero, evaluating 
my zero unit against each enemy unit 
in turn. Next, I fill in the correspond- 
ing matrix cell with that score. I might 
evaluate it with Vincke’s fitness func- 
tion (Fitness (S, m, n ) where S is the 
layout of the board, n are all of the 
enemy units, and m consists of my 





Fitness (S, m,n) given my new unit j 
attacking the enemy’s unit i in combi- 
nation with the configuration 
described by the cells of the previous 
row in turn. So for M(0,1) I would get 
the maximum of Fitness (S, m, n) 
where each time my unit 1 attacks the 
enemy’s unit 0, and my unit 0 attacks 
each of the enemy’s units in turn. I 
keep a pointer in cell M(O,1) to the cell 
in column 0 that I used to obtain the 
maximum score. Once | have done 
this for column 1, the largest score in 
column 1 represents the optimal con- 
figuration given those 2 units. The 
score in each cell M(i,j) represents the 
optimal score given my unit j attack- 
ing the enemy’s unit i, and with all of 
my units less than 7 on the board. I can 
repeat the process for each new col- 
umn for as many units as I want. Each 
cell has a pointer to the cell in the pre- 
vious column representing the rest of 
the configuration of units. When I get 
to the last column and have placed all 
my units, I can get the optimal config- 
uration of units by following the back 
pointers from the cell with the best 
score in the last column all the way 
back to the first column. 

The first column costs n evaluations 
of the fitness function. Each subse- 
quent column costs n*2 evaluations. 
For an eight on eight battle, this is 456 
evaluations to get the optimal solution 
to the problem. This is far fewer than 
the 16 million the article suggests. The 
algorithm does scale roughly as n%3, 
which can still be prohibitive for large 


“This is a classic resource allocation problem 
that can be solved quickly and easily using a 
technique known as dynamic programming.” 


-Rafael Baptista 


units, which for column zero is my 
single unit zero). The highest score in 
the column represents the optimal 
solution given that single zero unit. It 
is also trivially true that the score in 
each cell of the column M(0,/) repre- 
sents the optimal solution given that 
single unit attacking the 7 enemy unit 
(because there is only one such config- 
uration). For each subsequent column, 
I evaluate a new score for each cell in 
the matrix, where the new score for 
the cell M(z/) is the maximum of 
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numbers of units. To handle this, you 
can use the simple trick of threshold- 
ing. For each new cell M(i, j), only 
evaluate against the top k scoring con- 
figurations in the previous column. 
This immediately cuts the algorithm 
complexity down to n*2. You can 
prune it even further by not evaluating 
every cell in the matrix, but say only 
the cells likely to score highly. You 
might evaluate each cell in a given col- 
umn against a single random configu- 
ration of the previous units, and chose 
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you 





only the top / scoring cells to fill in. 
This reduces the problem down to a 
time complexity of n. Glorious linear 
time complexity! In a fight with 40 
units on 40 units andk=5 and/= Sit 
would cost 1,000 evaluations of the 
function. The solution is not guaran- 
teed to be optimal, but unless the 
inputs are particularly perverse it prob- 
ably will find the optimal answer. 
There are further optimizations. 
Fitness(S, m, n) is probably expensive. 
Because each cell represents a partial 
configuration of units, in each cell I 
could also store a partial evalua- 





evaluates the situation in an orderly 
and predictable way that allows you to 
re-use computation in a way that is 
hard to do with stochastic methods. 

By day, Iam the AI programmer for 
THQ’s upcoming excellent 3D space 
shooting game, EXCESSION. Our AI is 
very fast. 

Rafael Baptista 
GameFX 
via e-mail 


VINCKE RESPONDS. What the Viterbi 


algorithm essentially does is find a least- 


4o situation can be transformed into a win 
situation in as little as 700 iterations with- 
out using any heuristic. Together with a 
good heuristic, this number can even be 
decreased. Of course, the overhead is still 
higher than that of the Viterbi algorithm, 
which is why I’m hitting myself on the head 
for not mentioning it. One other advantage 
GAs have over traditional methods is that 
they present several solutions, which can 
be significantly different, at a given time. 
This can give you some measure of ran- 
domness, which can be great when you are 
dealing with something like map genera- 


tion of Fitness(S, m, n) that! use to “Our Al is also very fast. Maybe one day they can 


help me evaluate the next column 


faster. With a reasonable function, play with each other.” 
Swen Vincke of Larian Studios to Rafael 
go even faster you could decode as Baptista of GameFX 


one could probably get it down to 
about 1,000 pairwise evaluations of 


S| units and a few table lookups. To 


described above using a cheap 
approximation of the fitness function. 
You could chose the top q configura- 
tions from a table evaluated with the 
cheap function and then evaluate 
those g configurations using your more 
accurate and more expensive function. 
Hey, that gets us down to a constant 
number of evaluations of the expensive 
Fitness(S, m, n) function (and a linear 
number of partial evaluations of some 
cheaper function). So we might decide 
to evaluate Fitness(S, m,n)... oh, say 
ten times. This might make it possible 
to field very large numbers of units. Or 
you can use all the time you save for 
the real-time generation of fractal trees 
or some other useless diversion. Why 
does this work? If you think about it, a 
stochastic algorithm like Vinke’s 
spends most of its time evaluating con- 
figurations that are way off. It also re- 
evaluates very similar configurations 
over and over again. Dynamic pro- 
gramming zeroes in on the neighbor- 
hood of good solutions right away. 
Each time you add a unit, it considers 
only configurations that are similar to 
what it had determined was the opti- 
mal configuration with one unit fewer. 
Think about what a human would do 
when solving the problem manually. 
You would assign pieces to enemies 
one by one. Once in awhile when 
assigning a new piece you might reas- 
sign one you had assigned before 
because now you have that particular 
enemy covered by a better piece. The 
dynamic programming approach also 
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cost path, and you correctly point out that 
in order for it to do this optimally its com- 
plexity qualifies as m times n2, or if m=n, 
as n3. Using some heuristic such as select- 
ing a fixed number of alternatives as you 
do, or if you have access to some knowl- 
edge, a variable number of alternatives, 
significantly increases the speed of the 
algorithm, and indeed in most cases finds 
an optimal to near optimal sequence. You 
could, however, miss the global optimum. 
But | agree that for this particular problem 
and for real-time applications it is definite- 
ly superior to genetic algorithms, and | 
should’ve mentioned that in my introduc- 
tion where, as it stands, | might have given 
the impression that it didn’t get any better 
than n“m. The point of the article, howev- 
er, was to introduce the reader to genetic 
algorithms, and to show how they can be 
applied to a large class of problems where 
the search space is complex and where 
there are many local optimums. You could 
say that the first example, that of the orc 
problem, was a bit mischosen, given that 
there are faster ways of obtaining a good 
solution. Still, that, together with the TSP 
example, should have driven home the 
point that GAs can be very useful. The fact 
that GAs spend time evaluating bad con- 
figurations shouldn’t be regarded asa 
weakness, however. It is actually their 
great strength because it’s how they over- 
come the local minima problem. You can 
easily modify them not to exploit this by 
configuring them to use something like 
weakest chromosome replacement togeth- 
er with fit-fit selection. Using that, the 4o- 
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tion, for instance. All in all, GAs aren’t the 
be all and end all, but they do have signifi- 
cant advantages, and because of the ease 
with which you can adapt them to new 
problems, they are definitely worth consid- 
ering when you’re working ona tight 
schedule. 

Our Al is also very fast. Maybe one day 
they can play with each other. 


MacOS and Audio File Formats 


I read Chuck Carr’s Postmortem, 
“989 Sutdio’s NBA SHOOTOUT 98,” in 
the September 1998 issue of Game 
Developer magazine, and I noticed his 
mention of the problem of Mac- 
intoshes not being able to recognize 
.AIF audio files generated on an Intel 
PC. He mentioned that “Sound Forge 
and other PC audio programs don’t 
embed in their audio files the contex- 
tual information that the Macintosh 
needs to identify these files.” (p. 49). I 
have much experience with manually 
setting the file creator and type on HFS 
volumes. Carr didn’t mention the cool 
utility program called File Kit used for 
exactly this purpose. It allows the user 
to set the file type and creator, thus 
solving problems such as this. Apple 
should have included something like 
this with their operating system in the 
first place. 

Andrew Munkres 
via e-mail 
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IT’S RENDER HAPPY. Imagine your apps with cartoon rockets strapped to their feet. That’s how they run on the new IBM IntelliStation’ 


Its two screaming microprocessors make applications from vendors like Adobe, Avid and Alias |Wavefront siniaigs scream with delight 
What's that mean to you? Less time waiting. More time creating. Oh yeah, and happy killer graphics. Visit www.ibm.com/intellistation or call 
1 800 IBM 7255, ext. 5007. Careful, though. What you find could render you speechless 
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Virtually Human 


LEARNING MACHINES TECHNOLOGY 
GROUP (LMTG) recently released 
Nomad/Virtual Human SDK 1.2, a 
physical-simulation—based 3D anima- 
tion system and database that will gen- 
erate animation sequences for you. 

If you've ever tried to incorporate 
physics into a game engine, you may 
have realized that modeling leg-loco- 
motion is a challenge. LMTG has 
attempted to solve some of these diffi- 
culties with its SDK. Nomad features a 
library of 3D character animations 
based on the simulation of physics. The 
current release includes a quadruped 
class, a hexapod class, a bird class, and 
a humanoid bipedal class. 

But the SDK is more than a simple 
library; it’s an alternative to keyframed 
animation. You can specify weight, 
joint elasticity, and other physical 
attributes (including geometrical para- 
meters) to customize the Nomad char- 
acters. Built-in sensors and actuators 
(virtual muscles), allow you to design 
feedback controllers for Nomad charac- 


The Nomad/Virtual Human SDK has 
foot-terrain collision detection so 
characters can run over uneven 
ground. 
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ters to achieve a number of adaptive 
behaviors. Each character has a built-in 
locomotion controller, and the simula- 
tion includes accurate foot-terrain col- 
lision detection. This allows characters 
to walk and run adaptively over 
uneven ground (which you’re also free 
to design, along with custom obstacles 
and environment objects). 

The SDK contains other features 
such as real-time learning and adapta- 
tion, and the ability to access any nec- 
essary character geometry. The overall 
effect, LMTG claims, is a novel tech- 
nology that “injects personality into 
the simulated characters.” A profes- 
sional edition of the SDK includes an 
AI engine for each character class so 
that new animation behaviors can be 
synthesized at run time. As a result, 
the characters appear to learn. 

Nomad/Virtual Human SDK 1.2 is 
available for Windows NT, Windows 
95/98, and DOS. A single developer's 
license includes technical support and 
a free version upgrade for $189. The 
professional edition of the SDK sells 
for $2,500. 
~ Learning Machines Technology Group 

Sunnyvale, Calif. 

(408) 505-5398 

http://www.|mtg.com 


Easy 3D Audio 


QSOUND LABS has just launched 
QCreator, a 3D audio authoring tool 
for consumers and professionals. 
Using normal .WAV or .AIFF mono 
sound files, QCreator allows you to 
position sound within a three-dimen- 
sional space. When you open a mono 
sound file, QCreator automatically cre- 
ates an Edit Window to display the con- 
tents of the file as a waveform graph. A 
special Pan Tool lets you decide where 
the sound will appear in space — and 
how the sound will move. The result is 
a customized sound file delivered in 3D. 
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QcCreator will sells for $49.95, and is 
available for purchase from the 
QSound web site and RealNetworks' 
web site at http://www.real.com. 
™ QSound Labs Inc. 

Calgary, Alberta, Canada 

(403) 291-2492 

http: //www.qsound.com 


My First Tool Suite 


PARADIGM ENTERTAINMENT has 
announced the release of VisKit. This is 
a low-budget 3D rendering tool and 
API in C++ for constructing 3D appli- 
cations. The kit can be used for games 
and other applications including simu- 
lations, visualizations, interactive web 
applications, and real-time players. 

Small and fast, Viskit’s minimal run- 
time memory footprint and high- 
speed unrolled rendering loops help 
ensure improved real-time 3D applica- 
tion performance. Small footprint or 
no, VisKit still has more than 100 
classes and provides all the tools and 
features necessary to develop high-per- 
formance 3D applications. Features 
include scene management, hierarchi- 
cal state management, extensive vec- 
tor and matrix support, multiple cam- 
era support, particle systems, texture 
and image import in most of the pop- 
ular formats, automatic MIP-map gen- 
eration, and more. 

Viskit is layered on OpenGL and 
DirectSound, and is compatible with 
accelerated graphics. It sells for $99 
with no additional royalties or licens- 
ing fees. The system requirements are 
a Pentium 166 or greater, Windows 
95/98 or Windows NT 4.0, OpenGL, 
and Microsoft Visual C++ 5.0. An 
accelerated 3D graphics adapter is 
recommended. 
™ Paradigm Entertainment Inc. 

Dallas, Tex. 

(972) 960-2301 

http://www.viskit.com 
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©) Industry Watch 


by Alex Dunne 


PARIS-BASED PUBLISHER 
INFOGRAMES reported its results for 
the fiscal year ending June 30, and 
things look much rosier for the compa- 
ny this year. Infogrames posted rev- 
enue of $271 million, compared to 
$118 million last year, amounting to a 
$15.5 million profit. Last year, the 
company lost $6 million. The company 
attributed its success to several strong- 
selling titles, including V-RaLLy, which 
sold over two million copies world- 
wide. Company president and CEO 
Bruno Bonnell said that the company’s 
MISSION IMPOSSIBLE title, which was 
released in July 1998 for the N64, has 
reached the million-units—sold mark. 
DIAMOND MULTIMEDIA SYSTEMS 
reported financial results for its third 
quarter, which ended September 30. 
The company’s net revenues were up 34 
percent to $123.2 million, from $92.0 
million for the third quarter of 1997. 
The company incurred a net loss for 
the third quarter of $22.2 million, com- 
pared to a net loss of $2.5 million in 
the third quarter of last year. William 
Schroeder, president and CEO, said that 
the net loss was partly as a result of 
“price protection charges related to our 
Monster3D II product, whose supply, 
along with that of other Voodoo2-based 
graphics subsystems, exceeded demand 
during the third quarter.” 

AUREAL SEMICONDUCTOR, which 
builds the Vortex audio chip for 
sound cards (including Diamond’s 
Monster Sound MX300) received a 
patent for a “Method and Apparatus 
for Efficient Presentation of High- 
Quality, Three-Dimensional Audio, 
Including Ambient Effects.” It was the 
ygth patent for the company, and it 
has 39 additional audio patent appli- 
cations in the works. The company’s 
portfolio of interactive audio patents 
are related to all sorts of head-related 
transfer function (HRTF) technologies, 
including measurement HRTFs, ren- 
dering HRTFs, and implementation 
HRTFs. Creative Labs, however, hasn’t 
been too thrilled with some of 
Aureal’s marketing and advertising 
claims, apparently. CL filed a lawsuit 
against Aureal claiming “false adver- 
tising” and “unfair business prac- 


tices.” The Creative complaint centers 
primarily on a comparison chart pre- 
pared by Aureal highlighting feature 
differences between their technology 
and CL’s SoundBlaster Live! 

AMERICA ONLINE signed a multititle 
distribution agreement with online 
game developer, VR-1. In the deal, 
VR-1 will be providing AOL with three 
new pay-to-play games in 1999. The 
games included in the agreement 
include VR-1 CrossroADs, NOMADS OF 
KLANTH, and THE S.A.R.A.C. PROJECT. 
Each of these games was built around 
the VR-1 Conductor technology plat- 
form, and each supports hundreds of 
players in a single arena. AOL has the 
option to license up to four additional 
VR-1 titles. VR-1 also developed the 
first two pay-to-play games for 
Microsoft’s online gaming service (now 
called the MSN Gaming Zone) and has 
several international distribution agree- 
ments in place, including one with 
BT’s WirePlay in the U.K. 

HERE’S ANOTHER ENGINE for your 
growing list of “technologies for sale.” 
3DO announced plans to license the 
engine for REQUIEM: AVENGING ANGEL, 
which is slated for release in January 
1999. The Requiem Engine, according 
to Trip Hawkins, “has a notable pedi- 
gree.” OK, Trip. Actually, this probably 
isn’t just hot air. The company’s 
Cyclone Studios division, which is 
headed up by General Manager Helmut 
Kobler, also developed last year’s 
UprisING title and does indeed have 
good technical chops. We’ll find out 
soon enough. 

ACTIVISION AND VIACOM CONSUMER 
PRODUCTS (the licensing division of 
Paramount Pictures) announced a 10- 
year alliance that will allow Activision 
to develop and publish interactive 
entertainment titles based on the Star 
Trek franchise. Under the terms of the 
agreement, Activision has obtained 
the exclusive worldwide publishing 
rights for multiple platforms to all 
Star Trek properties, subject to the 
expiration of existing publishing 
agreements that Viacom Consumer 
Products currently maintains with 
respect to certain Star Trek properties. 
The deal also provides Activision with 
exclusive worldwide rights to any new 
television series or motion picture 
based on Star Trek. Activision intends 
to release its first Star Trek title based 
on Paramount Pictures’ holiday ’98 
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feature film, Star Trek: Insurrection. The 
announcement represents the first 
time that Viacom Consumer Products 
has entered into an exclusive umbrella 
deal with an independent entertain- 
ment software publisher. 

SILICON GRAPHICS took a 10 percent 
stake in graphics chip maker Real 3D 
and said that the two companies would 
undertake cooperative marketing, tech- 
nology, and business development. 
Under the terms of the agreement, Real 
3D will be a preferred provider for 
future SGI workstation products. SGI 
will assist in the marketing of Real 3D 
products such as RealScan 3D, and the 
two companies will collaborate on 
future software technologies and initia- 
tives. SGI’s investment is worth 
between $20 million and $25 million 
to the Orlando, Fla., company, accord- 
ing to industry sources. Intel owns 20 
percent of Real 3D, while Lockheed 
Martin, which founded Real 3D in 
1996, owns the remainder. 

Separately, SGI and Real 3D agreed 
to end litigation and entered into a 
royalty-free graphics patent cross- 
license. The agreement adds to licens- 
ing deals Real 3D already has with 
Lockheed Martin, Intel, and Sega. 
Looks to be an amenable way to end a 
lawsuit, don’t you think? 


GDC sedi bi Dalinare 


BALTIMORE CONVENTION CENTER 
Baltimore, Md. u 
December 10 & 11, 1998 
$225 
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NuMega s 
TrueTime 


by Rom Fosmer 





s Dan Teven mentioned last 
december, Game Developer 
magazine has reviewed a slew 
of profiling tools recently. This is no 
accident. We’ve made a very conscien- 
tious effort to cover these types of 
tools for a good reason. While every- 
one is busy jumping on the 3D hard- 
ware acceleration bandwagon, it’s easy 
to forget the mantra of the game devel- 
oper: quick, tight code. Just because 
everybody assumes that game players 
have 3D accelerators doesn’t mean that 
we can code like we’re building a word 
processor. 

TrueTime integrates right into the 
Visual C++ development environment. 
This integration, combined with its 
excellent user interface, makes it easy 
to profile an application. The downside 
is that its suggested retail price is 
slightly higher than that of VTune, but 
you can get a free evaluation copy first 
from Compuware to determine 
whether it’s worth the investment. 

THE TRUETIME TRIALS. Installing 
TrueTime is easy, and once completed, 
the application adds a special toolbar 
to your Visual C++ IDE. With this tool- 
bar in place and a project loaded, you 
have the option of instrumenting all or 
just part of your application. Profiling 
your application is as easy as selecting 





the “Rebuild with TrueTime” 
button. Your application 
recompiles with TrueTime 
instrumentation, links to 
TrueTime, then executes. 
Then, as your application 
runs, TrueTime records its 
timing information. When 
your application terminates, 
TrueTime brings up a win- 
dow that displays various 
performance statistics for 
that profiling session. 

I began testing TrueTime 
using my favorite example, a 
Direct3D Immediate Mode application 
that translates an object to some dis- 
crete 3D location. Along the way, I 
need to create a transformation matrix, 
which is generally composed of rota- 
tions about the x, y, and z axes, plus a 
translation. This code is part of an 
example that I use in my course on 
code optimization to illustrate how to 
use the matrix manipulation routines 
provided with Direct3D Immediate 
Mode. Unfortunately, this example cre- 
ates a transformation matrix that is 
composed of a translation and three 
rotations in a mathematically ineffi- 
cient manner (four matrix multiplies 
that are easily simplified), while also 
being inefficient with temporary stor- 
age. Straight out of the SDK, this code 
exhibits numerous inefficiencies. 
Because I already have an optimized 
version, I wanted to see how TrueTime 
would profile the original source. 

I first created a test harness that sim- 
ply called one particular code segment 
from the Direct3D application in a 
loop. With this working harness, it was 
simply a matter of pushing the 
TrueTime button in the IDE to recom- 
pile my application with TrueTime 
instrumentation. During this process, 
the application’s source files get recom- 
piled with invisible wrappers around 
all the function entry and exit points, 
which puts these into a TrueTime data- 
base. TrueTime can then measure the 
time spent in a function, as well as the 
time spent in each function that a par- 
ticular function calls — right down to 
operating system calls. 


Ron Fosner works on fast 3D rendering code at Data Visualization, is the author of 
OpenGL Programming for Windows 95 and Windows NT from Addison-Wesley, 


and has taught course on code tuning at the Game Developer’s Conference and the 
Win-Dev conferences. 
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When TrueTime finishes compiling 
your application, you run your instru- 
mented application via another 
TrueTime button on the IDE, which 
launches the TrueTime monitor. The 
TrueTime monitor is a status window 
that shows the timing information for 
your application. TrueTime continues 
to monitor your program until it has 
terminated, at which point the initial 
TrueTime interface comes up (Figure 1). 

The TrueTime interface is highly 
interactive, and allows you to quickly 
drill down into your program to find 
the areas that take the most time. The 
left-most column shown in Figure 1 is 
the Session Window and it simply dis- 
plays information about the current 
TrueTime session. The interesting 
information is contained in the Filter 
Pane, located in middle column. From 
the highlighted bar in this column you 
can see that MATRIX.EXE, the test har- 
ness, takes up over 99 percent of the 
time. Just below that, you can see that 
“System” takes up the remainder. The 
item highlighted in the Filter Pane dis- 
plays relevant data in the right pane, 
called the Session Data Pane. By select- 
ing the executable, the Session Data 
Pane displays timing data for the entire 
program. The other top-level tabs in 
the Filter Pane allow you to filter the 
display by various function definitions. 

In Figure 1, the Session Data Pane 
indicates that the function takes up 
the majority of time spent in the pro- 
gram. The “% in Function” column 
tells how much time was spent just in 
a particular function. The “% with 
Children” column shows how much 
time was spent in a function plus all of 
the other functions that were called 
while we were in this function. The 
last two columns describe how many 
times the function was called and the 
average execution time of the function. 
There are many other options that can 
be displayed in the Session Data Pane, 
including the first, maximum, and 
minimum execution times of the func- 
tion, the average execution time 
including children, and so on. 

The Session Data Pane illustrates 
TrueTime’s excellent user interface. 
Double-clicking on the MatrixMult func- 
tion in the Session Data Pane brings 
up the Function Details window 
shown in Figure 2. The two pie chart 
sections give details about both the 
functions that call MatrixMult and func- 
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tions that MatrixMult calls itself. As you 
can see, only the passi function calls 
MatrixMult. More interesting informa- 
tion can be gleaned by examining the 
child functions that MatrixMult calls. 
Additional details appear when the 
cursor hovers over a particular area. 
For instance, in Figure 2, my cursor is 
over the yellow slice of the pie chart 
and a pop-up informational window 
has appeared. The green slice indicates 
time spent in the function itself, the 
other slices indicate time spent in 
other functions called from MatrixMult. 
Of particular interest are the yellow 
and blue slices, which contain 
D3DMatrix::Operator(), and D3DMatrix: :Op- 
erator()_25f0. The former is the compil- 
er-generated name for the “( )” opera- 
tor (the parentheses operator) for the 
D3DMatrix class from the DirectX SDK. 
The latter name is a bit obscure, but 
thankfully a button in the upper left 
corner of the window displays the 
source code of the currently selected 
function. Double-clicking on the 
D3DMatrix: :Operator()_25f0 line in the 
Function Details window brings up 
D3DMatrix: :Operator()_25f0. If we click on 
the source button, the Session Data 
Pane will then display the source for 
D3DMatrix: :Operator()_25f0. The left 
columns indicate the count and the 
execution time percentage for each 
line of the program. Unlike Intel’s 
VTune, which disassembles source code 
and displays assembly instructions and 
performance information, TrueTime 
stops at the source code level. 

With TrueTime, it’s just as easy to 
profile a retail build as a debug build. 
If you do, that you'll find that the oper- 
ator() measurements go away. However, 
if you’re like me, you spend most of 
your time running the debug build, 
and it’s easy to get a skewed view of 
your program’s performance, because 
an often called utility class contains a 
high overhead in debug mode. 
Another nice feature of TrueTime is its 
ability to display the results of more 
than one timing session in multiple 
windows simultaneously. 

Thanks to TrueTime’s timing infor- 
mation, you can make modification to 
your code based on timing results, test 
new these new strategies, and verify 
their results. These are all features that 
should be present in any good profiler. 
But TrueTime make these tasks very 
easy thanks to its seamless integration 
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with the development environment. 

On the negative side, TrueTime is 
an instrumenting profiler. This means 
that every function call that you’re 
profiling has to have a TrueTime 
wrapper around it before it’s executed. 
This means your program will typical- 
ly run two to three times slower than 
the non-instrumented version. 
Additionally, TrueTime by default 
won't measure any threads that are 
outside of your process. If you want a 
more “system-wide” profile, NuMega 
has something it calls Quantum 
Technology. Basically, it’s simply a 
method of including or excluding 
time spent in other processes. 
However, this doesn’t extend into sys- 
tem calls. This means that if you’re 
thrashing virtual memory, you won't 
see it. But by far I feel the biggest neg- 
ative is its price: $499 for the stand- 
alone version (up from $399 in 
September 1998, and now more 
expensive than VTune). With the cur- 
rent version, it’s impossible to turn 
profiling on or off — it just runs 
while your application is running. | 
pointed out this fact to the folks at 
NuMega, and they informed me that 
they’re building this feature into the 
next version. 

Despite some of these problems, | 
feel that TrueTime is excellent for any 
programmer looking to find out how 
his or her application really spends its 
time. And, given the fact that 
TrueTime is also bundled with 
NuMega’s DevPartner Studio (which 
includes utilities such as Bounds- 


TrueTime 1.0 for Visual C+: 


Company: Pros: 
Compuware (NuMega) 
Nashua, N.H. 

(603) 578-8400 


http://www.numega.com | tion. 


Price: 
$499 (DevPartner Studio 
is $1,199). 


System Requirements: 
Windows 95/98, 
Windows NT 4. Requires 
Visual C++ 4.2 or higher, 
Visual J++ 6.0 or Visual 
Basic 5.0. Requires a 
Pentium processor, 32MB | 
RAM, and approximately 
17MB of disk space. 
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1. TrueTime features an 
easy-to-use interface for 
viewing timing informa- 


2. It integrates well with- 
in Visual C++ 


3. TrueTime makes it 
easy to profile release 


FI tE 2. TrueTime’s Function 
Details window. 


Checker and SoftICE), it may be a bet- 
ter deal to purchase it within that 
suite of products if you don’t already 
own them. 

So, how does TrueTime compare to 
VTune? Well, it’s a little easier to use 
and the integration with the Visual 
C++ IDE is excellent. While VTune will 
force you to profile the entire system, 
TrueTime will profile just your applica- 
tion. Additionally, TrueTime just pro- 
files source code, not the actual assem- 
bly-level statements. If you need to 
profile either the system or you do 
occasional assembly code optimiza- 
tions, then you might want to stick 
with VTune. But if you just want to get 
up and running quickly, and you use 
Visual C++, TrueTime may be the prod- 
uct for you. 


Cons: 
1. TrueTime only works 
with Microsoft develop- 
ment tools. 


2. It slows down the 
speed of your applicatio 
while it’s testing it. 


3.It’s slightly (about $70) 
more expensive than 
Intel’s VTune. (These 
tools are getting a bit 
pricey.) 


4. TrueTime doesn’t drill 
down into assembly like 
VTune can. 
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In our world great looking cutscene video is being produced 
on-time and on-budget, without integration hassles. There is an 


understanding of how video in games CAN work. Welcome to 


our world. 


Journeyman 
Video for the digital world 





800.234.4460 A CTl Group Company www.journeyman.com 


by Jeff Lander 





Mighty Morphing Mesh Machine 





Now, think about the fun you could 
have morphing between a 3D model of 
your brother and the monkey — that 
could make your week. Most 3D ani- 
mation packages will allow you to do 
this, but what you might really be 
looking for is a real-time 3D demo fea- 
turing your brother in some sort of 
failed lab experiment that you could 
mercilessly blow away. Or something 
like that... 

To engage in this advanced level of 
fun, you need a method for morphing 
between two 3D shapes. This tech- 
nique is not only amusing, but also 
quite useful. 3D morphing can help 
create organic animation that would 
otherwise be difficult to develop. 


Morphing and 
Real-Time 3D Animation 


Ar use for 3D morphing is 
smoothing between keyframes. 


In games such as QUAKE 2, you may 
read that the animation in-betweens 
are interpolated. I have discussed 
before how in QUAKE (and many 3D 
action games) each frame of anima- 
tion is actually represented by an indi- 
vidual mesh. By sequencing through 
those meshes, the illusion of anima- 
tion is created. However, the original 
object frames are created at a set frame 
rate, say 10 frames per second (FPS). 
This means that the smoothest those 
animations can play back is at that 
original 10 FPS. If, for example, the 
engine is actually displaying at 60 FPS, 
each frame of character animation is 
held for six frames. That’s quite a 
wasted opportunity. Smoother anima- 
tion could be achieved by morphing 
from one frame to the next over those 
six frames. That is exactly what the 
“feature hypers” (you know, the fea- 
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ture-happy marketing dudes) are talk- 
ing about when they talk about inter- 
polated in-betweens. But what exactly 
is being interpolated? 


LERP = Morph 


his is an important equation in the 

game programmer’s arsenal. Many 
programmers who have been working 
in 3D for some time take this for grant- 
ed as widely known information. But 
judging by the mail I get and the com- 
ments I see in the public forums, there 
are many individuals who aren't up-to- 
speed on how morphing works. The 
secret to object morphing is that the 
only thing that changes between the 
two models is the vertex positions in 
the object (a little white lie — I’ll get to 
the truth later). When you morph 
between 3D objects, you are doing a 
“linear interpolation,” or LERP, 


* 
a- 


FIGURE 1A. Your model at rest, for 
the first frame of animation. 


ost game people have played around with those programs that will 
morph between two graphic images. They allow you to take a picture 


of your brother and a picture of a freckle-faced baboon, play with the 


sliders, and enjoy hours of endless amusement. 


between the vertex positions in the 
two objects. For this technique to 
work, the two models you are morph- 
ing between must have identical vertex 
counts, and the vertices must corre- 
spond to each other. This means that 
vertex 1 on the first model should end 
up in the position of vertex 1 in the 
second model. The easiest way to make 
sure that the models are created cor- 
rectly is to actually create the second 
model by moving the vertices in the 
first model into the shape you want. 
That way, the models will interpolate 
exactly the way you created them. By 
now you have the models and want to 
morph between them. The formula for 
a LERP between two values is 


InBetween = Valuel + ((Value2 - Value) * 
lerpValue) ; 
Where lerpValue is a float between 0 and 1. 


Now, this formula needs to be applied 


FIGURE 1B. The same model, frame 
two. You’ll get smoother animation 
by morphing between frames. 





























jeffl@darwin3d.com with suggestions for the next keyframe. | 


Morphing between a lounging postion on the beach and a slave position at his desk, 
_ Jeff can be found at Darwin 3D working on real-time game technology. Emaii him at | 
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to every parameter that will vary during 
the morph. For a 3D vertex coordinate, 
those parameters would be the x, y, and 
z values for that point. This is where I 
explain the truth behind that little 
white lie. There may be more parame- 
ters than just the coordinates which you 
wish to interpolate for an individual 
vertex. If your game engine supports 
real-time lighting and your model data 
contains vertex-normal information, for 
example, you may want to interpolate 
the normal values as well. Also, if your 
model contains vertex color informa- 
tion, an interesting effect may be creat- 
ed by interpolating the color. 

What about textures? If your 3D 
model contains texture coordinates, 
you may want those coordinates to 
change over time as well. However, 
there are many possible pitfalls associ- 
ated with morphing textures. Small 
changes in UV coordinates can cause a 
major shift in the appearance of a 
model that may not be desired. 
Likewise, it may be more interesting to 
change the texture completely for the 
second position. This complicates 
things a bit. However, if the UV coordi- 
nates stay constant throughout the 
morph and only the texture changes, 
image processing techniques can help. 
By using a 2D dissolve to create a blend- 
ed image between both textures, this 
will smoothly change along with the 
model. These blended textures could 
either be prebuilt as a texture anima- 
tion or actually created on-the-fly, if 
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Format 


By By 7 
.3DS 3DS R4 128... =ssissa, 
3DSAschl 305Re 14 #=5+4 
.DXF Autocad —1,2,3,4,6,7,8 1,3,5,6,7,8. 
LWOB Lightwave 5 5 
-OB) Wavefront  2,3,6,7,8 2,3,6,7,8 
Game Exchange Nichimen 7 7 
-HRC Softimage 8 8 
MAX 3DS MAX 2 2 
Maya ASCll Maya 6 6 
VRML VRML 2,7,8 2,7,8 
X Direct X 2,7,8 2,7,8 


.3DS R4 
.3DS MAX 
Alias 
Hash 
Lightwave 
Maya 8 
Softimage = 


Program Names: 
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PHA and D3DTOP_BLENDDIFFUSEALPHA in 
DirectX 6 (See “Multitexturing in 
DirectX 6,” Game Developer, September 
1998). With multitexture hardware 


possible. Multitexture hardware can 
provide a hardware-accelerated method 
for blending between two textures via 
methods such as the D3DTOP_BLENDFACTORAL- 


LISTING 1. The morph code. 











#define LERP(a,b,c) (a+ ((b - a) * c)) 
MAMA 
// Procedure: morphModel 

// Purpose: Does the Morph for the Model 

// Arguments: Pointer to main bone 

LALO CL OL 

GLvoid COGLView: :morphModel(t_Bone *curBone) 

{ 

/// Local Variables nn 
int loop, pointloop; | 
float *dest,*src1,*src2, ratio; 

TN LLL 
if (curBone->visualCnt > m_curVisual) 


{ 


// FRAME 1 

// FRAME 2 

// DESTINATION FOR MORPHED FRAME 
// GET MORPH VALUE (0 - 1) 


srci = curBone->visuals[0].vertexData; 
src2 = curBone->visuals[1] . vertexData; 
dest = curBone->visuals[2] . vertexData; 
ratio = m_Slider->GetSetting() ; 
// LOOP THROUGH THE VERTICES 
for (loop = 0; loop < curBone->visuals[0].triCnt * 3; loop++) 
{ 
// GO THROUGH EACH ELEMENT IN THE VERTEX STRUCTURE 
for (pointloop = 0; pointloop < curBone->visuals[0].vSize; pointloop++) 
{ 
// THE NEW POSITION IS A LERP BETWEEN THE TWO POINTS 
dest[(loop * curBone->visuals[0].vSize) + pointloop] = 
LERP(srci[(loop * curBone->visuals[0].vSize) + pointloop], 
src2[(loop * curBone->visuals[0].vSize) + pointloop], ratio) ; 


} 
// morphModel 
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becoming more common, this could 
be an area to add value to your hard- 
ware-accelerated application. 

This algorithm is actually very easy 
to get up and running. You can see the 
code for a 3D morph in Listing 1. One 
easy Optimization to make would be to 
precalculate the deltas between each 
parameter to remove a subtraction 
operation. In the case of an animation 
system, predividing the deltas by the 
number of desired in-betweens would 
turn it into a pure addition operation. 

That’s all there is to 3D morphing. 
Given how easy a 3D morph actually is 
to implement, I wonder why we don’t 
see it more in real-time 3D games. 
There are many uses for this technolo- 
gy. Beyond creating in-betweens for 
character animation, morphing is an 
excellent way to change the shape of 
characters. It can also be used to create 
facial animation and other special 
effects. Hopefully, we will start to see 
more in the next generation of real- 
time projects. 


Getting Your Model Data 


Ss O, you're ready to start morphing 
every object you can get in your 
hands. That brings up an important 
question. How do you get your hands 
on model data? When it comes to game 
companies with staff artists and tool 
programmers, many rely on high-end 
animation packages with SDKs. These 
toolkits allow the programmers to write 
plug-ins that allow them to get to the 
data directly. This is not always possi- 
ble. Some programmers do not have the 
money, time, or experience to get mod- 
els this way. The other option is to use 
a public 3D file format. The ideal file 


FIGURE 2A. Your “brother” mapped 
onto a 3D model. 
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format contains all the information 
that the application requires and is easy 
to use. The ideal format is also public, 
meaning that information is publicly 
available describing the format. Code 
samples are even more desirable. 

So, which file format is the best one 
for you? Table 1 (see page 16) contains 
a list of several file formats along with 
some information about them. This is 
by no means comprehensive, but the 
list offers a glimpse of what’s out there. 
Ease-of-use is an opinion gathered from 
my own experience and from dis- 
cussing it with other programmers. 

The key to finding a format to sup- 
port in a custom tool is to pick a for- 
mat that contains all the information 
that is critical to your application. If 
your game engine uses vertex coloring, 
make sure the format supports that 
feature. It’s also helpful to pick a for- 
mat that is supported by your or your 
artist’s favorite art tool. There are com- 
mercial 3D file converters available, 
but they add cost and an additional 
step to the production process. Also, 
using an ASCII format makes checking 
your data and debugging the process 
much easier. 

I have found that one of the easiest 
to use and most widely supported for- 
mats is the Wavefront .OBJ format. It 
contains support for UV coordinates as 
well as for vertex normals. The format 
is so easy that you really don’t even 
need a spec to write a file loader. Listing 
2 shows a simple cube in .OBJ format. 
Lines that begin with the pound sign # 
are comments and can be ignored. The 
initial o cubei defines the name of the 
object. That is followed by the mtl1ib 
cube.mtl. This line describes a file that 
contains material information about 
the object. But more on that later. 


FIGURE 2B. The original figure mor- 
phed into a baboon. 
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The next block of information actu- 
ally describes the vertices. Each line 
starts with a v and is followed by the x, 
y, and z coordinate values. The com- 
ment at the end actually tells you the 
number of vertices. But, that doesn’t 
seem to be a standard feature of this 
format, so you shouldn’t count on it. 

The vn block gives the x, y, z, values 
for the normals in the model and the 
vt block describes the texture coordi- 
nates. The texture coordinates can be 
either two coordinates (u and v) or 
three (u, v, and w). For most real-time 
applications, however, the w value 
could be ignored. A 3D model may 
have normals or texture coordinates, 
or both, or neither, but it obviously 


LISTING 2. An OBJ Cube. 


0 cubel 






ntliib cubeet 


-5.000000 -5.000000 -5.000000 
-5.000000 -5.000000 5.000000 
-5.000000 5.000000 -5.000000 
-5.000000 5.000000 5.000000 
v 5.000000 ~5.000000 -5.000000 
v 5.000000 -5.000000 5.000000 

v 5.000000 5.000000 -5.000000 | 
v 5.000000 5.000000 5.000000 ts” 
# 8 vertices | 


-=- = = 


<= 








vn -1.000000 0.000000 0.000000 sts 
vn 0.000000 0.000000 1.000000 

vn 1.000000 0.000000 0.000000 — 

vn 0.000000 0.000000 -1.000000 

vn 0.000000 -1.000000 0.000000 

vn 0.000000 1.000000 0.000000 

# 6 normals 


vt 0.000000 0.000000 
vt 0.000000 1.000000 
vt 1.000000 0.000000 
vt 1.000000 1.000000 
# 4 texture vertices 


usemtl mati_FACE 

f 1/2/1 2/4/1 4/3/14 
f 1/2/41 4/3/1 3/1/1 
f 2/2/2 6/4/2 8/3/2 
f 2/2/2 8/3/2 4/1/2 
f 6/2/3 5/4/3 7/3/3 
f 6/2/3 7/3/3 8/1/3 
f 5/2/4 1/4/4 3/3/4 
f 5/2/4 3/3/4 7/1/4 
f 5/2/5 6/4/5 2/3/5 
f 5/2/5 2/3/5 1/1/5 
f 3/2/6 4/4/6 8/3/6 
f 3/2/6 8/3/6 7/1/6 
# 12 elements 
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must have the vertex values. 

The final block in the file begins with 
the usemtl mati_FACE. This says to the 
loader, from now on all faces defined 
should use the mati_FACE material. This 
material is defined in the cube.mt1 file. 
All lines that begin with an f describe a 
face in the model. Each face can be 
composed of multiple vertices. Each 
face is not required to have the same 
number of vertices. However, because it 
is more efficient for 3D hardware if all 
faces have the same number of vertices, 
I make sure this is the case. I could tes- 
sellate the face to triangles at run time, 
but this is really easy to do in the mod- 
eling program. Therefore, I just make it 
a requirement that all models are trian- 
gulated before exporting. A pop-up box 
in the loader can warn users that a face 
is not triangulated. 

In the face statement each vertex is 
defined by three elements separated by 
forward slashes that describe the ver- 
tex, texture coordinate, and normal for 
that face. The values are indices into 
the list of elements already defined. 
It’s important to notice that these 
indices are one-based instead of zero- 
based. In a file that only has vertex 
coordinates (and not normals or tex- 
ture vertices), the vertex index will be 
followed by two slashes as in f 1// 2// 
3//. Likewise, if there is a vertex and a 
normal, the format is f 1//1 2//2 3//3 
and so on. Each vertex in the line is 
separated by a space. 

You can see a material file in Listing 
3. The file can describe multiple materi- 
als. Each one begins with newmtl and the 
name of the material in this case 
mati_FACE. The next lines Ka, Kd, and Ks 
respectively describe the ambient, dif- 
fuse, and specular color for the materi- 
al. The Ns term describes the specular 
highlight. I have never had a need for 
theNi and illum term, though they are 
there if you want them. Finally, the 
map_Kd describes the diffuse map applied 
to the object. In other words, this is the 
texture map that should be applied to 
the surface. I use this name as the name 
of the file loaded by the application. I 
just convert the image to a .TGA or 
.BMP file to make use of existing file 
loading code. 

See there, I said it was an easy format. 
Actually there are other blocks that may 
be useful in a real-time simulation that 
are not in my sample file. The g com- 
mand allows faces to be grouped 
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together so the file can contain multi- 
ple objects even in a hierarchy. This is 
definitely handy when working with 
hierarchical characters. 


Writing a .OBJ File Loader 


he MFC CString class makes string 

manipulation much easier than in 
basic C. For custom tools, this means 
loading ASCH file formats is easier than 
ever. My strategy is to load a line of 
text from the file and then break it up 
into a string of words in a CStringArray 
structure. If you haven’t used the 
CString class, it will bring back fond 
memories of BASIC string handling. 

I don’t want to go through the entire 
-OBJ loader here. You can just grab it 
off the web site (http://www. 
gdmag.com). However, my strategy for 
loading an .OBJ file is to pass through 
the file once, determining how many 
vertices, normals, and texture coordi- 


nates for which I need to allocate 
space. Then, all the actual coordinate 
values are simple to load in. The only 
tricky part comes in when I want to 
load in the face indices. You can see 
how I approached that in Listing 4. 
The point of this loader is not for me 
to show highly optimized, well formu- 
lated code samples for loading these 
files. My code here certainly is not fine- 
tuned in any sense of the word. The 
great thing about creating production 
tools is that, unlike almost all other 


LISTING 3. MTL file for the Cube. 






newmtL mati_FACE 3 =———<CSts 
Ka 0.5000 0.5000 0.5000 
Kd 0.7000 0.7000 0.7000 
Ks 1.0000 1.0000 1.0000 — 
Ns 50.0000 

Ni 1.0000 

illum 2 

map_Kd FACE.pic 


LISTING 4. Handling a face line in an .OB). 











// Procedure: HandleFace 
// Purpose: 
// a face Structure 


// Arguments: Array of words from the face line, ae to put th 
Not an Official OBJ loader as it doesn’t handle more then. 
This only handles Triangles 

MEL 


void HandleFace(CStringArray *words,t_faceIndex a 


// Notes: 
// 3 vertex polygons. 


{ 


/// Local Variables LLL / 


int loop; 

CString temp; 

CString yStr ,nStr, str; 
int nPos,tPos; 


MULL 
// LOOP THROUGH THE 3 WORDS OF THE FACELIST LINE, WORD 0 HAS a 


for (loop = 1; loop < 4; loop++) 
{ 
temp = words->GetAt(loop) ; 
tPos = temp.Find(“/’); 
vStr = temp.Left(tPos) ; 
temp.SetAt(tPos,’ *); 
nPos = temp.Find(‘/*); 


face->v[loop - 1] = atoi(vStr); 
face->t[loop - 1] = atoi(tStr); 
face->n[loop - 1] = atoi(nStr); 

} 
} 
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Handles the Face Line in an OBJ file. 


// HOLD POINTERS TO ELEMENT POINTERS 


// GRAB THE NEXT WORD 
// FACE DATA IS IN THE FORMAT vertex/texture/normal : 
// FIND THE */* SEPARATING VERTEX AND TEXTUR 
// GET THE VERTEX NUMBER — : 
// CHANGE THE “/* TO A SPACE: so. 
// FIND THE “/’ SEPARATING TEXTUR 
tStr = temp.Mid(tPos + 1, nPos - tPos - 1); 
nStr = temp.Right(temp.GetLength() - nPos - 1); // GET THE NORMAL NUMBER © 
// STORE OFF THE INDEX FOR THE VERTEX 
// STORE OFF THE INDEX FOR THE TEXTURE = 
// STORE OFF THE INDEX FOR THE NORMAL 


MIN1 HandleFace WMMMMMMMM MMMM MMU = 


Extracts index info to 


// GET THE TEXTURE NUMBER 
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coding in the game industry, the focus 
is not directly on the speed of the rou- 
tine. It doesn’t have to be very fast. In 
fact, when working on tools, it is often 
better to sacrifice speed for clarity. 
Often, a tool that you create now and 
will have a long life and pass through 
many hands after you. This is not usu- 
ally true of the actual game code (no 
matter what your producer may want 
to think) as most core game routines 
are rewritten for each project. Tools 
tend to linger. 

The point of showing these types of 
file loading routines is to demonstrate 
how easily it can be done. | talk to pro- 
grammers who Say they understand the 
algorithms but have no models with 
which to work. They are not comfort- 
able writing a 3D Studio MAX plug-in 
to get models. I hope that this shows es 
that very commonly used 3D file for- 
mats can be easily integrated into your 
own production tools. Once you build 
up a library of routines like this, you 
can easily get models to work within 
your game applications. If you create a 
loader for a commonly used format, 
there are models everywhere that you 
can use. For actual production applica- 
tions, I tend to create custom binary 
formats because they are compact and 
exactly tuned to the application. But by 
loading a general format, you can easily 
make a file converter. 

This month, I have provided an appli- 
cation that allows you to load two .OBJ 
files that have identical vertex arrange- 
ments. You then can use the slider to 
morph between the two. The program 
can handle objects with and without 
texture mapping. Grab it at the Game 
Developer web site at http://www.- 
gdmag.com. Special Thanks to Bennie 
Terry for providing the model, and to 
Eddie Smith for providing the texture 
map for the LAG14 character from their 
real-time action title, ARIES PROJECT. @ 
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by Mel Guymon 


So, You Want to 


Make a Console Game? 


of hardware compatibility issues, and a 
thriving rental industry are leading 
more and more PC developers to 
release console versions of their most 
popular titles. 

This month, we’re going to switch 
gears and examine some of the aspects 
of developing content for the two con- 
sole powerhouses, the Sony PlayStation, 
and Nintendo’s N64. With the help of 
two local developers, Crave 
Entertainment and Snowblind Studios, 
we'll look at the problem from the 
standpoint of “How They Did It” and 
try to pre-emptively address some of the 
technical dos and don’ts you’re likely to 
come across. For those console veterans 
out there, consider this a refresher 
course and a discussion of what some of 
your peers in the industry are doing. 


Sony's PlayStation 


Oo start off, we’ll look at the aging- 

but-still-popular Sony PlayStation. 
With more than 30 million units on the 
worldwide market (as of February 1998), 
the PlayStation user base is staggering. 
And with games such as FINAL FANTASY 
VII, GRAN TURISMO, and the Resident 
Evil franchise, the platform shows no 
sign of slowing down. To round out the 
PlayStation perspective, we’ve inter- 
viewed the SHADOW MADNESS team over 
at Crave Entertainment. 
THE GAME. SHADOW MADNESS (due out in 
Spring 1999) is Crave’s attempt to break 
into the lucrative RPG franchise busi- 
ness. The game play follows the format 
perfected by Squaresoft’s FINAL FANTASY 
VII with real-time 3D (RT3D) characters 
exploring static backgrounds, the everp- 
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resent story-telling FMVs, and fully 
immersive RT3D combat arenas. 
Production on the title started back in 
mid-1997, when, after an initial design 
phase, the art team was assembled and 
work began on the FMVs and the more 
than 800 interactive backgrounds for 
the game. The engineering team was 
assembled some months later, when the 
art path and toolset for actually getting 
data into a 3D engine was created. 
THE SONY APPROVAL PROCESS. Every PSX 
game that you see on the shelf has 
Sony’s stamp of approval on it. This 
means it has met the rigorous standards 
of content and quality that Sony uses to 
judge games released on it’s platform. 
How does this work? Well, first of all, 
there are a limited number of slots given 
out each year to developers. Some of the 
major players, such as Eidos and Square 
for example, are allotted slots carte- 
blanche, based on past performance. 
But most developers must first go 
through an initial design and planning 
phase to get Sony to buy-off on their 
game concept. During the development 
lifecycle, Sony keeps tabs on the prod- 
uct’s content and quality, and in most 
cases, has the authority at any time to 
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ou’re not alone. When you compare the $900 million in revenue generated 
by the PC gaming industry to the $25 billion brought in by the console mar- 


ket, it’s not hard to see why. High volume sell through, a virtual absence 


reject the product based on it’s failure to 
meet their company standards. 

Sound strange? Well, imagine if, 
when the time came to get your alpha 
milestone approved for your PC title , 
that you had to submit a version to Intel 
or 3Dfx along with the one you send up 
to your publisher. In essence , that’s 
what it comes down to. 

DEVELOPMENT STRATEGY. Early on, the 
developers at Crave chose the PSX as the 
target platform. One of the many rea- 
sons for going this route was the PSX’s 
ability to seamlessly display full-length 
prerendered FMVs, a tool the developers 
planned to exploit fully as part of the 
story-telling process in the RPG. With 
this exceptional functionality came a 
slew of technical challenges, which had 
to be addressed before the game went 
into full production. 

The most challenging aspect of devel- 
oping on the PSX was the limited 
amount of storage space (2MB of RAM) 
available to the artists — texture maps, 


SHADOW MADNESS. 
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FIGURE 2. Weeble mode. 


color look-up tables, animations, geom- 
etry, and static backgrounds all have to 
fit in this window of memory. To create 
an immersive gaming experience then, 
the folks at Crave opted for two differ- 
ent modes of play. 

Weeble mode (Figure 2), is used by the 
player when navigating the environ- 
ment. This mode is characterized by low- 
resolution character models animated 
on a scrolling or static background. Most 
of the memoty is taken up by high-reso- 
lution background images and overlays. 

The hurdles in weeble mode dealt 
mainly with cinematic feel and camera 
control, because this is where most of 
the non-FMV storytelling takes place. 
Each static background, then, became 
equivalent to a stage on a film set. By 
taking advantage of overlays for creating 
parallax, the team was able to create 
seemingly 3D environments using only 
static backgrounds. To do this, the team 
incorporated knowledge gained from the 
film industry — camera control and 
field-of-view manipulation became key, 
with each artist responsible for creating 
the correct mood in his or her area. 

In weeble mode, the characters take 
up a relativley small percentage of the 
viewing area. Consequently, they can be 
lower-resolution (around 100 to 140 
polygons) and use fewer textures, there- 
by allowing more characters on screen. 
Additionally, their animations can be of 
lower complexity. Finally, the savings in 
texture space, polygon storage, and char- 
acter animation translates directly into 
additional space for background images 
and overlays. Determining the right bal- 
ance of textures, geometry, and anima- 
tions early on proved crucial to complet- 
ing the project in a timely manner. 

Battle mode, as illustrated in Figure 3, 
is used for close encounters with NPCs 
or enemy characters. Battle mode uses 
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FIGURE 3. Battle Mode 





fully interactive 3D environments with 
higher-resolution character models. 

Battle mode is closer to what players 
have come to expect in RT3D. Here, the 
focus shifts from telling the story to 
dynamic real-time action. Fully immer- 
sive, interactive environments, with an 
active camera that can swivel and pan 
around the battle arena, characterize this 
phase of the game. In battle mode, the 
characters are higher-resolution, and the 
environments are composed mainly of 
textured 3D objects, with only cursory 
background images for environmental 
texture mapping. Because the characters 
take up much more screen space in bat- 
tle mode, they need to have a propor- 
tional amount of complexity associated 
with them. Here, the characters have 
roughly twice the number of polygons 
(300 to 400 polygons each) and a much 
smoother set of animations. (Crave’s 
engine took advantage of the new .HMD 
format for PSX, which allows real-time 
interpolation between keyframes, giving 
a much smoother feel with a lot fewer 
stored keyframes.) 
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TECHNICAL TRICKS AND CHALLENGES. Overall, 
the problem that the artists kept run- 
ning into was how to efficiently use the 
2 MB of RAM they had in their budget. 
Because the background images 
couldn’t really be optimized, the bulk 
of tweaking time was spent on the 3D 
characters and geometry. 

The characters in the game were 
expensive mainly because of the tex- 
tures and animations associated with 
them. Consequently, this is where most 
of the effort was put to try to streamline 
the already expensive process. 

VERTEX COLORS INSTEAD OF TEXTURES. Vertex 
colors were used in addition to, and in 
place of, textures for each character (for 
more on vertex coloring, see “Painting 
With Vertex Colors” Game Developer, 
November 1998). Colors were applied 
directly in 3D Studio MAX with the ver- 
tex coloring tool. Figure 3 shows an 
example of characters in the game that 
were painted almost entirely using ver- 
tex coloring. 

-HMD AND KEYFRAME INTERPOLATION. When 
it came to determining a format in 
which to store and access the 3D geom- 
etry and animation information, the 
developers had three options: MIME, 
.TOD/.TMD, and the new .HMD for- 
mat. Each had its respective advantages 
and disadvantages, but .HMD was the 
only unproven format because it was 
new and there was relatively little docu- 
mentation on it. The one big advantage 
that .HMD had was the freedom it pro- 
vided for the programmers to access the 
keyframe data. This allowed them to 
generate algorithms for real-time inter- 
polation, so that an animation that 


PlayStation Art Path 
Prerendered 
Backgrounds 


Power- 
Animator 8.5 


RT3D Characters 
and Environments 


Power- 
Animator 8.5 


Y Y 


.DXF Format ; 
3D Studio 


Y = Y MAX 2.0 


3D Studio ¥ 


Photoshop 


MAX 2. 
2-0 —-HMD 


Y Export Tool 


-HMD 
Export Tool 


FIGURE 5. The PlayStation art path. 





GAME DEVELOPER 





a 





ARTIST’S VIEW 


classically would have used 30 frames 
could be created with 7 keyframes. 
Having an engine that provides for real- 
time interpolation between keyframes 
means that each animation sequence 
can be made up of very few actual data- 
points, with the engine providing the 
smooth transition between keyframes 
and poses. Overall, this meant a much 
smaller allocation of expensive memory 
space for any given animation, and a 
larger total number of animations 
allowed for each character. According 
to Crave, the game could not have been 
finished without using the new .HMD 
format, which to date has not been 
used on any published title. 

TOOLS. Once the technical hurdles were 
addressed, the team had to choose tools. 
Two main goals needed to be achieved: 
rapid generation of high-quality preren- 
dered PowerAnimator content, and 
fully-textured and animated RT3D char- 
acters. For this task, the developers 
chose PowerAnimator 8.5 and 3D 
Studio MAX 2.0. The proven high-quali- 
ty rendering capabilities of Power- 
Animator were augmented by interfac- 
ing with Renderman. 

Figure S shows the art path Crave used 
to create content for their title. Most 
RT3D modeling was done within 3D 
Studio MAX, with the bulk of cinematics 
and static backgrounds done with 
NURBS in PowerAnimator 8.5. The 
developers wrote a plug-in to export 
geometry, texture information, and ani- 
mation from 3D Studio MAX to the 
-HMD format, consequently, all the 
RT3D data had to pass through MAX. 

In addition to the off-the-shelf tech- 
nology, there were several in-house 
tools developed, including one which 
allowed the artists to physically place 
each texture in memory. This allowed 
for the most efficient use of space 
when storing differently sized textures 
with variable bit depths, a process that 
is hard to automate effectively. 

At the time of the interview, the 
product was well on it’s way to comple- 
tion. SHADOW MADNESS had just 
reached alpha, and was on track for a 
Q1 1999 release date. 


Top GEAR OVERDRIVE 
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Ithough it arrived relatively late in 

the game, many developers think 
the polished look and feel of the N64’s 
technology were worth the wait. 
Boasting a user base of over 7 million 
units (as of September 1998), the latest 
version of Nintendo’s console line has a 
lucrative market ready to be exploited 
by the savvy developer. To examine the 
N64 platform development process, 
we'll look at a game that is just finishing 
production over at Snowblind Studios, 
TOP GEAR OVERDRIVE. 
THE GAME. TOP GEAR OVERDRIVE (TGOD) 
is Snowblind’s first title, and is based 
on the Top Gear franchise created by 
Kemco of Japan. The self-proclaimed 
goal at Snowblind was to create a rac- 
ing game with a more “arcade-like” 
feel. The game boasts over 30 tracks, 
myriad driving conditions, and over 20 
cars to choose from, including the new 
VW Beetle. The fact that the game is 
near completion and has only been in 
production for about nine months is a 
testament to the efficiency and techni- 
cal know-how of the six-man develop- 
ment team working at Snowblind. 
DEVELOPMENT STRATEGY. With some experi- 
ence on the platform prior to starting 
work on TGOD, Snowblind wasn’t 
going into the situation well, er, with 
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blinders on (sorry, couldn’t resist that 
one). As with the PSX, the sheltered N64 
market promised to be extremely lucra- 
tive to the developers. The relative 
dearth of racing games on the N64 was 
an added bonus. The N64’s rendering 
features included several that were not 
available on PSX, such as perspective 
correction, tri-linear filtering, and Z- 
buffering, to name a few. And the lack 
of a need for any cinematics meant 
there was no real need to go with a CD- 
based system. 

Obviously, getting the artists off to 
an early start on a development cycle 
this short was crucial. In order to famil- 
iarize the art team with the limitations 
of the system, their strategy, says Raoul 
Said, a programmer at Snowblind, was 
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FIGURE 7. PC-compatible version of Top GEAR OVERDRIVE. 
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to “... have one programmer jump 
ahead on the game framework and car 
physics code (on OpenGL/PC) while 
another programmer brought our N64- 
specific code up to speed, while the 
third programmer helped out on tools. 
The game ran on N64 dev stations from 
very early on.” Figure 7 shows the PC 
compatible version of the game. 

This gave the art team access to the 
nuances of N64 development prior to 
entering full production, which allowed 
them to streamline their art path to 
what was necessary and efficient. 
TECHNOLOGY TRICKS AND CHALLENGES. As with 
the PSX, the development challenges 
were somewhat offset by myriad tech- 
nical features aimed at making produc- 
tion easier. Additionally, the rendering 
and texturing features found on the 
N64 give the games a softer, more pol- 
ished look. 

The two biggest potential pitfalls 
faced by the art team were the total on- 
screen polygon count (total rendered 
polygons limited to between 1,500 to 
2,500 polygons), and the limitation on 
memory storage (4MB of general pur- 
pose ram, of which 1.1MB were set aside 
for tracks, textures, and cars). 

The challenge of managing scene 
complexity is not unique to consoles, 
but is instead faced by almost all devel- 
opers working with RT3D content. The 
solution was found through the tried- 
and-true method of iterative testing. 
Tracks were generated using the custom 
lofting tool the team developed (dis- 
cussed hereafter), then tested out with 
terrain and geometry added. 
Adjustments were made over the course 
of testing to get the approximate poly- 
gon count as close to the target as possi- 
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ble. This, of course, grew easier with 
practice, until the artists got to the 
point that they could create a track from 
start to finish in under three months 
(for one artist working on one track). 

The second challenge, that of total 
memory storage, was tackled by setting 
a limit on the total number of polygons 
in a track (around 10K polygons, includ- 
ing physics barriers), thereby setting a 
limit on the actually size of the geome- 
try in memory. Surprisingly, those inno- 
cent little polygons turned out to be 
gluttons for space. In addition to the 
raw geometry, additional data tied into 
radiosity information (for soft shadows) 
and visibility set information had to fit 
into the same block of memory. Figure 8 
maps out the memory usage. 

Finally, the team needed to take 
advantage of N64’s ultra-fast texture 
cache. Aside from the 4MB of general 
purpose RAM, the N64 comes equipped 
with a super-fast texture cache, capable 
of extremely high transfer speeds. The 
downside is that the pipeline is relatively 
small. To use the cache to full capacity, 
texture maps had to be small; equivalent 
to 32x32x16-bit, or an equivalent size on 
disk (textures could have large dimen- 
sion, with a correspondingly lower pixel 
depth, 64x64x4-bit, for example). So, 
large areas of complex terrain required 
detailed texture work, and the large 
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background images had to be cut up into 
smaller individual pieces in order to 
meet the size requirements. Figure 9 
shows an example of an environment 
map used for one of the sky domes. This 
texture map, a tiling sky piece, had to be 
cut up into 36 smaller textures and 
mapped onto a 170 polygon dome. 

THE INTENSITY ALPHA TEXTURE. [A4 for short, 
the intensity alpha texture is a feature 
found only on the N64 Platform. Used 
extensively by the artists at Snowblind, 
the IA4 texture provides a space-effi- 
cient way to create texture maps. 
Here’s how it works. You create a tex- 
ture using a grayscale palette, and then 
choose two bounding colors to use as 
your color wash. The bounding colors 
act like a gradient tool, in that they 
match up to the texture map corre- 
spondingly to the lightest and darkest 
areas of the texture. For example, let’s 
say I created a grayscale texture map 
with shades ranging from black to 
white, and then picked my bounding 
colors to be blue and red. The result 
would be a colorized texture map, with 
the black areas receiving a blue tint, 
the white areas receiving a red tint, and 
the gray areas receiving a purple tint. 
You basically create a texture that takes 
up the space of a grayscale texture, yet 
is fully colored. 

TEXTURE MIRRORING. [he artists at 


An environment map used for one of Top GEAR OVERDRIVE’s sky domes. 
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Snowblind also used the mirrored tex- 
ture, another feature unique to the N64. 
This feature allows the artist to flip a 
texture along one or both axes of a quad 
polygon, a method that would other- 
wise require additional tesselation to 
produce the requisite polygon edges at 
the mirror boundaries. 

THE TOOLS. In its most basic form, the 
task for the art team boiled down to 
one thing: create texture-mapped poly- 
gons. To accomplish this, the group set- 
tled on 3D Studio MAX 2.0 as its single 
off-the-shelf technology. The open 
plug-in architecture allowed for rapid 
toolset generation, and within only a 
few weeks of going into full production, 
the engineering team at Snowblind had 
come up with a suite of plug-ins to aug- 
ment the already powerful modeling 
tools in 3D Studio MAX. The primary 
tool was the track lofting plug-in, 
which allowed the artists to create and 
test initial track layouts at the rate of 
one per day. This rapid turnaround was 
crucial to tweaking the playability of 
the tracks, and the entire process of get- 
ting a track into the engine was accom- 
plished with only a few button clicks. 





LOPERS 


Other plug-ins included lofting and 
sculpting tools, a texturing tool for 
dealing with huge numbers of texture 
maps on a single mesh (a must for 
large, multi-material geometries). 

The folks over at Snowblind may 
well have a hit on their hands. The 
game had that clean, polished feeling 
characteristic of the N64, and it was 
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FIGURE 10. N64 art path. 
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fun to play. And considering this six- 
man crew will have created the game 
from start to finish in just under ten 
months, their achievement becomes 
even greater. This group will be one to 
watch in the future. 


he hazards and limitations associ- 

ated with console development 
pale in comparison to the benefits. The 
stable technology base, though limit- 
ing at first glance, inevitably allows 
developers to focus on ways to get the 
job done, instead of trying to figure out 
exactly what their target platform can 
do. This is a subtle yet critical distinc- 
tion, and is leading more and more 
developers down the path of console 
development. @ 
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Trends in the Graphics Board Market 





This is the job of the board maker. 
Only in the case of ATI and Matrox, 
where the chip maker and the board 
maker are one and the same, is there a 


. : : direct connection between the technol- 


} | ogy at the silicon level and its market- 

_ | ing to the consumer. Companies such 
as Diamond Multimedia, Creative Labs, 
and STB Systems are chip agnostic, and 
in this month’s column we’re going to 
explore primarily the chip-agnostic 
graphics board industry to determine 
how these companies will fare in the 
coming year. The 3D graphics hard- 
ware business is getting merciless. The 
board vendor is on the front line, and 
is going to feel the pain more acutely 
than anyone else in the industry. The 
consumer, on the other hand, is going 
to be getting even more 3D power for 
even less money. 


Love and Hate Relationships 


he relationship between chip- and 

board-makers is one that they both 
resent. Why it even exists is our first 
port of call, followed by why both par- 
ties wish that it didn’t have to exist. 
Before I go any further, I should proba- 
bly put a proviso in here about 3Dfx, 
the most visible 3D graphics company 
in the game industry. 3Dfx is unique in 
having been successful at building its 
brand and influencing the end user of 
its products directly through its mar- 
keting efforts. Thus, 3Dfx has achieved 
a unique position in the industry, but I 
see the company’s success in this 
regard as an exception rather than the 
norm. Companies such as Nvidia, S3, 
and 3Dlabs do market their brand, but 
their influence with end users doesn’t 
rise to same level. As a result, these 
chip companies, including 3Dfx, put 
their energies into supporting the 
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board vendor brands of Diamond, 
Creative Labs, or STB and others. The 
reason for this deference to board ven- 
dors is distribution and support. 

Board vendors control the distribu- 
tion channels. This gives them the con- 
nection to the customer, and invariably, 
they have to create a support structure 
to serve that customer. By contrast, chip 
vendors’ customers are their board and 
system OEMs. The value of board ven- 
dors is their experience supporting end 
users, and their realization that there is 
more to delivering a graphics product 
than producing a working piece of sili- 
con. That something more is software 
drivers. Chip vendors have enough on 
their plate dealing with the every rising 
complexity of chip design and manufac- 
ture. They may not be as savvy as board 
vendors when it comes to writing soft- 
ware drivers. From the time a finished 
chip is ready to go, to the time it is 
ready to be shipped to a customer may 
take weeks or months, depending on 
the quality of the drivers. This lag in 
time between when a chip vendor 
thinks a product is ready to go, and 
when a board vendor thinks it is ready 
to go is one reason why the two entities 
don’t always see eye to eye. 

In addition, chip-agnostic board ven- 
dors are usually vying with each other 
to differentiate products based on the 
chipset using software features and dri- 
ver performance. The exception to the 
rule was 3Dfx, which reduced the 
board vendors’ value-add by delivering 
a finished board and driver product 
that didn’t leave much room for differ- 
entiation. If you read the round-ups 
and reviews of 3Dfx boards, you may 
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ame developers have been targeted extensively over the past four years 
by chip makers trying to convince them that their feature set, or partic- 


ular approach to 3D hardware, is ideally suited to their applications. 


Ironically, chip makers rarely ever get to connect with the end user. 


have found that they were quite amus- 
ing — reviewers desperately tried to 
justify their preferred choices, but there 
was hardly any difference from one 
Voodoo2 board to the next. The 
Voodoo2 reduced board vendors to dis- 
tributors and support staff for what was 
essentially a purely 3Dfx product. 

So, the question arises, how much 
value-add do board vendors actually 
provide? Taking a cue from Voodoo2, 
it would seem not to be very much, but 
Voodoo2 was a 3D-only product target- 
ed at a very specific hardcore gamer 
demographic. Go into the realm of 2D, 
and games aren’t the only problem. 
Every piece of software that runs on a 
PC could be a nightmare support prob- 
lem. Maybe chip makers, who all make 
2D/3D chips, could deliver a finished 
board product themselves, but they 
realize that it might involve supporting 
OS/2 or Linux, or someone’s ten-year- 
old DOS application. So, although the 
board vendor is really a tier of distribu- 
tion for the chip vendor, it’s also a 
buffer against consumer support. 

Yet, forces beyond the control of 
chip and board vendors threaten this 
delicate graphics ecosystem. The 
biggest impact in 1998 on the board 
business was to be the entry of Intel 
into the market. Intel has managed to 
successfully devalue the graphics chip 
business to such an extent that the 
effects are going to be felt in the indus- 
try for some time to come. John Latta 
of the market research firm, 4° Wave 
(http://www.fourthwave.com), was the 
first person to publicly decry the pric- 
ing policies of Intel with regard to its 
Intel740 graphics chip ($7 a chip). 
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Brave man, Mr. Latta. A devalued 
graphics chip market drives prices 
down on all components and board 
products associated with it. As we go 
into 1999, we can expect much more 
aggressive pricing on board products, 
some very shaky board vendor finan- 
cials, but healthy volumes for the per- 
formance leaders based on the pricing. 
It’s good news for the consumer. It’s 
good news for Intel, which just wants 
to sell more CPUs. But at what cost to 
the graphics board industry? 


The Market 


he cost for the industry, on the sur- 

face of it, doesn’t look bad. “The 
1998 add-in board market is expected 
to grow 65 percent over 1997, and then 
will slow down to an average growth of 
18 percent per year up through the end 
of 2001,” says Bob MacQuillan, senior 
research editor at Jon Peddie Associates 
(http://www.jpa.com). “The overall 
add-in board market will enjoy good 
growth. However, the entry/value and 
mid-range categories in the mainstream 
segment will be virtually eliminated as 
the market moves toward sub-$1,000 
PCs that utilize embedded designs of 
graphics controllers and core logic.” 

Mr. MacQuillan’s comments point 
out the real effect of Intel’s entry into 
the market in 1998, and its plans to put 
3D graphics in core logic in 1999, and 
come out with a lower-cost Intel740 
follow-up, too. Competition in the 
entry-level and mid-range is only for 
the brave with deep pockets, or a 
strong constitution. 

The expansion of the market for 
higher-performance 3D parts is the 
bright spot for the graphics board ven- 
dors. I think it might turn out that 1999 
brings in enough volume in the perfor- 
mance sector to offset the entry-level 
and mid-range business woes. It may 
not, however, bring with it a compara- 
ble increase in revenues and profits. The 
battle between Nvidia, $3, Matrox, ATI, 
3Dlabs, and 3Dfx for performance and 
brand leadership is just as likely to drive 
prices down as anything Intel could, or 
would do. Without exception, in 1999 
the chip companies are going to move 
0.25 micron chip designs, which means 
cheaper and faster designs. Further, the 
multitexture engine is here to stay, so 
the interest in new 3D technology will 
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still be there, although market drivers 
remain stagnant. So all this competition 
is strictly for games — no other software 
needs the power. Having everyone chas- 
ing the game enthusiast may be good 
for game developers, but it’s not neces- 
sarily good for an industry that may be 
crowding too many competitors into 
too small a space. 

Figure 1 shows how important these 
high-performance parts are to the mar- 
ket. Jon Peddie Associates defines the 
category of performance as typically 
characterized as having either hardware 
floating point triangle set-up (such as 
ATI Rage Pro, Nvidia Riva 128, and so 
on) and/or high fill-rates (such as 3Dfx 
Voodoo Graphics, NEC PowerVR, and 
others). The Tiburon, Calif., firm defines 
mainstream as controllers containing 
2D plus minimal 3D capabilities (“free- 
D”). Examples include the S3 Virge 
series and the Trident 3DImage 975. 

Performance parts are the only value 





parts of the board vendor’s product line. 
It used to be that a board vendor could 
look forward to selling a mature product 
into mid-range and entry-level markets, 
but that opportunity is dwindling. 
Board vendors make their money from 
creating awareness among consumers of 
cutting-edge products. They make their 
money from selling premium products. 
It seems as if a sterling year awaits the 
board business in 1999, but again, it’s a 
question of how board vendors will 
make money if the graphics market is 
being devalued by the presence of Intel, 
and by the strength of the sub-$1,000 
PC. It’s all up to the players. 


The Players 


c 
n Table 1, I have designated Tier 1-3 


board vendors. The classification is 
partly based on channels, partly on 
exposure to brand name PC OEMs, and 





FIGURE 1. 3D controllers by segment: 1997 to 2000. (Source: Jon Peddie 


Associates) 
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TABLE 1. A list of the most recognized board names by category. 





TIER 1 VENDORS TIER 2 VENDORS TIER 3 VENDORS 
ATI Technologies California Graphics ASUStek 
Creative Labs Canopus Leadtek 
Diamond Multimedia E4 Jaton 
ELSA/Hercules iXMicro Expert Color 
Intel Number Nine Techworks 
Matrox Radius 
STB Systems VideoLogic 

Wicked3D 
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FIGURE 2. Branded 3D add-in board market by channel. (Source: Jon Peddie 


Associates) 


partly on volumes. It’s something that 
hasn’t been done for graphics board 
companies, but is done for PC OEMs. It 
is not a definitive list of the Tier 3 ven- 
dors, but it does give you the graphics 
board landscape as it is today. I have 
given Intel a Tier 1 position, rather 
reluctantly, but they do have a strong 
brand. Also, Iam being generous to 
ELSA/Hercules because of ELSA’s 
strengths in Germany. In fact, I believe 
that in reality there should only be five 
Tier 1 companies: ATI, Creative, 
Diamond, Matrox, and STB. That’s five 
companies serving ten Tier 1 PC OEMs. 
These Tier 1 vendors are under the 
greatest pressure in the coming year. 
They face squeezed margins, compet- 
ing product lines from their chip sup- 
pliers (Nvidia’s TNT versus the 3Dfx 
Banshee is one good example), and ris- 
ing costs as they struggle to differenti- 
ate their brands. ATI seems to be the 
strongest company, having a healthy 
OEM presence, and some sound design 
wins for its Rage chipset. Creative is by 
far the best retail company in the Tier 1 
arena. However, when it comes to 
branding graphics boards for a games 
audience, Diamond has done a very 
good job in North America. The weak- 
est brand in the Tier 1 group is STB, 
which tends to be much more focused 
on supporting the Tier 1 PC OEMs 
using its manufacturing skills. 

The Tier 2 vendors are, in some 
ways, more interesting than the Tier 1 
board vendors. They have to work 
harder at differentiating their products. 
Canopus innovates in the hardware 
design by adding features and 
enhancements that the other board 
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vendors may overlook. Wicked3D, the 
Metabyte board company, has pio- 
neered stereo graphics by delivering 
drivers that support the widest ranges 
of stereo-enabled games. E4 has exten- 
sive support for DVD, and so forth. It’s 
tough for the Tier 2 vendors because 
they are at the mercy of allocation by 
the chip vendors, more eager to get 
their three months of shelf space fame 
with Diamond and Creative, or to sup- 
port STB supplies to Compaq, Dell, and 
Gateway. So, Tier 2 board vendors may 
innovate and target a game-playing 
audience better than the Tier 1 player, 
but they have to battle for channel 
recognition, and they don’t get the 
best support from the chip vendors 
who look to their volume customers. 
At the tail end are the Tier 3 vendors, 
which happen to be the biggest volume 
takers too. They take mature products, 
they make low-priced solutions, and 
they can ship hundreds of thousands 
of units a month, in excess of the Tier 
1 brand names. As a game developer, 
you may never have to support a Jaton 
board, for example, but within the 
board industry, Jaton and its like play 
an important role delivering boards to 
all those resellers and PC-makers who 
don’t want to pay a premium fora 
brand name, but do want to get their 
hands on good graphics boards, or the 
products of a recognized chip vendor. 
The non-branded board vendors supply 
in excess of the branded board vendors 
by a factor of 2:1. It used to be that Tier 
3 vendors were seen as adding little 
value, and in bringing product prices 
down. They were the volume supplier 
of mature products. However, as com- 
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petition among chip vendors heats up 
in the performance sector, the Tier 3 
vendors will get to compete head to 
head with Tier 1 and Tier 2 players by 
getting product before it matures. 
Unfortunately, the Tier 3 vendors 
rarely have the resources, or the com- 
mitment, to raise awareness of their 
brands, so although they may end up 
shipping more product than the brand 
companies, no one outside the indus- 
try gets to hear much about it. 

One mustn’t forget that the PC 
graphics business is bigger than the 
sum of these vendors — over 80 mil- 
lion units in 1999 alone. There’s room 
for a lot of players, but whether there is 
value for the players to stay in the busi- 
ness is debatable. For example, I have 
relegated Number Nine to a Tier 2 posi- 
tion because, despite having some 
excellent technology, the company has 
failed to deliver a Tier 1 position in any 
of its markets. Number Nine doesn’t 
sell the cheapest boards, and it certain- 
ly doesn’t make the worst products. 
Yet, the company finds it hard to mine 
its niche of the high-end business desk- 
top, and it cannot generate the money 
it needs to move its development in a 
direction that would make it competi- 
tive. VideoLogic may also seem con- 
tentious for a Tier 2 position, but the 
company has never done anything of 
any significance in the board market, 
and the fact that NEC breathed life 
into the company through PowerVkR is 
not influencing their board business. 
With technology, both these compa- 
nies are good acquisitions: Number 
Nine is very close to Silicon Graphics 
and, of course, VideoLogic is very close 
to NEC and Sega. 

With such premier names showing 
signs of strain in the board business, it 
makes you wonder which is the next 
brand name to feel the pinch. The 
answer may lie in the dynamics of the 
channel. 


The Graphics Channel 


f you look at the distribution pie 

chart supplied by Jon Peddie 
Associates (Figure 2), the distribution 
and OEM channels take an even bite of 
the sales pie, and interestingly enough, 
direct sales are showing some strength 
as well, specifically as a result of the 
Web-savvy game enthusiasts. With dis- 
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tribution and OEM channels practical- 
ly eating up whatever profit margin 
potential there is, the only real prof- 
itable outlets for board vendors are 
direct sales. Yet, the brand name board 
companies are very cautious not to be 
seen in competition with their distribu- 
tion channels. There’s a little pull and 
push there. 

It seems that the direct channel may 
afford an opportunity for the Tier 2 
vendors to establish themselves. Tier 3 
vendors are primarily OEM and distrib- 
ution bound, with little in the way of 
retail. Therefore, the channel may have 
already decided how the board busi- 
ness shapes up. 

Looking at the channels in more 
detail, we can see some patterns emerg- 
ing. Diamond is very strong in the 
North American retail market, but is 
under increasing pressure from 
Creative. ATI and Matrox fare better in 
Europe and international markets than 
they do in North America, but in gen- 
eral, have strengths in the PC OEM and 
reseller channels. ATI’s retail presence 
is the stronger of the two. STB has yet 


to make any breakthroughs in retail, 
and is 80 percent PC OEM business. It 
faces pressure from ATI, Matrox, and 
Diamond, but it always has. 

Jaton, Leadtek, and Expert Color sell 
through distributors serving resellers and 
systems integrators. You may find the 
odd low-cost controller from the Tier 3 
vendor in a retail store, but it won’t be 
sitting on the shelf at CompUSA or 
Electronic Boutique. They could break 
out with product, but none of the Tier 3 
vendors are inclined to package their 
products for the consumer. 

So, the status quo is pretty much set, 
but there is hope in the Tier 2 section. 
Companies such as Canopus, 
Wicked3D, California Graphics, and E4 
want to be consumer friendly. They 
have the hunger, and they have to dif- 
ferentiate their products much more 
than any Tier 1 or Tier 3 vendor would 
have to do. They are relatively free to 
make new channels, or to go into areas 
that the big companies are precluded 
from, such as having a more aggressive 
direct sales strategy. However, Tier 2 
vendors need volumes to get better 


chip pricing and support from the 
semiconductor companies, and that’s 
where they face the biggest challenge. 
To get volumes, Tier 2 vendors need 
OEMs. To get OEMs, they need strong 
retail, or branding, or manufacturing 
capability. It all costs money. To get 
money in a price-squeezed market, 
they need volume. 

However, I believe that board compa- 
nies have to change. They need to 
become leaner, and they need to change 
the way they do business to take into 
account the new business dynamics. 
This may be the best chance for a Tier 2 
or Tier 3 vendor to break into the Tier 1 
category, but it doesn’t look like the big 
five are going anywhere for now, profits 
or no profits. In the middle of all of this, 
the consumer is going to get a smorgas- 
bord of very good 3D products, in differ- 
ent flavors of chips, and from a diverse 
group of board vendors. Cheap, too. A 
16MB, Banshee board from Creative 
Labs retails for about $99, having gone 
down from $149 in the space of six 
weeks, or less. Brutal business, but some- 
one’s got to doit. & 


1999 3D GRAPHICS MARKET OUTLOOK 


IF THE 3D GRAPHICS MARKET IMPACTS YOUR BUSINESS, THEN YOU NEED EXPERT ANALYSIS. Omid Rahmat, former VP of Jon Peddie & Associates, 
and industry consultant, has taken an in-depth look at the hottest technologies and the companies creating them. Who 
owns the market? Who is up and coming? Where should YOU place your development resources in 1999 and beyond? 


This 30 page report will help you target and support the right hardware while cutting down your production schedule. 


Help avoid costly mistakes by taking advantage of this detailed report, including: 


Projected sales through 1999 


The impact of the 3D API 
OEMs role in Consumer 3D 


The factors driving consumer 3D 


Movers, shakers, influencers and up-and-comers 


Company information from 3Dfx, 3Dlabs, Cirrus Logic, S3, nVidia, ATI, 


Evans & Sutherland, Intel, Intergraph, Fujitsu and more! 


The 1999 3D Graphics Market Outlook is the only report designed specifically for the game development community, 


giving you exactly what you need to make great 3D games, on time and on budget. 


To find out more, or to pre-order your copy at the special introductory price of $495, please see: 


http://www.mfgame.com/research/ 


Available Q1 1999 
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of massively multiplayer games. The 
games we develop (such as AIR WARRIOR, 
MULTIPLAYER BAT- 
TLETECH, ALIENS 
ONT BNI or bele! 
LEGENDS OF 
KESMAI) 


sup- 
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ous players via the major online service 
providers (America Online, Compuserve 
and others) and over the Internet (at 
http://www.gamestorm.com). Our games 
are played much longer than most stand- 
alone boxed games. For example, two of 
our Current games are over ten years old, 
and several were released more than five 
years ago. All of these games have been 
updated many times as the underlying 


computer technology has evolved. 

















A year ago, we decided to change 
radically our methods of developing 
games. We were dissatisfied with our 
maintenance costs, the effort required 
to achieve our desired level of quality, 
and our inability to predict production 
schedules. This article is a description 
of what we did to achieve this change, 
although you should view what you’re 
about to read as an “after-action 
report” — our development processes 
are continuously evolving to meet our 
objectives. 





A re you sick of not being able to 
predict when the development of 


“| your game will. be complete? Are you 


tired of creating bug patches for a game 
that shipped months ago? Are you hav- 
ing trouble adding a feature that the 
new vice president of marketing 
demanded halfway through develop- 
ment? If any of these scenarios sound 
familiar, let me offer you a way of deal- 
ing with them. " 


Engineering discipline, as I define it, » 


is determining and applying processes 
to the development of game software 
with the goal of improving the quality, 
maintainability, extensibility, and 
schedule visibility of the software. 
Being able to deliver these particular 
elements consistently in game software 
is unprecedented, in my experience. 


What Is the Reality of Current 
Game Software Development? 


hile both the team and man- 

agement share a desire for the 
elements of quality, maintainability, 
extensibility, and schedule visibility in 
their software products, the primary 
mission of most game developers is to 
ship a fun game by Christmas. The 
desirable ship dates for most products 
are dictated by the realities of the retail 
market. With the majority of all soft- 
ware Sales occurring between the 
months of September and January, the 
pressure to ship before Christmas is 
incredible. The final ship date for 
Christmas is about two weeks before 
Thanksgiving, given the normal retail 
distribution delays and processes. Some 
products succeed when shipping out- 
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side of this narrow window, but typi- 
cally this success is limited to about ten 
highly promoted and anticipated titles. 
Odds are that you are not working on 
one of these titles. 

Almost everyone with experience in 
game development has had to work on 
someone’s legacy code. Most experi- 
enced programmers have had to fix an 
incompatibility or bug for a product 
developed by someone else, or have 
had to start a sequel from a previous 
product code base. In general, game 
software isn’t written to be maintain- 
able. Rather, the primary goal is getting 
the code “finished enough” to ship it 
as a commercial product. As such, 
many game developers believe that any 
documentation and coding standards 
come at the expense of getting the 
game done sooner. This lack of docu- 
mentation and standards worked for 
most game developers for a time, as 
teams used to be relatively small and 
time to market was the most important 
issue. But times have changed. 


Why Consider An 


-. Engineering Discipline? 


Bhe main reason that we at Kesmai 
considered a new way to develop 

software was that the methods com- 
monly used in the game development 
business weren’t working well. Our 
products’ life cycles were 
longer than those of most 
game companies, and 
our maintenance costs 
were prohibitive. We 
also noticed that most 
products in the games 
business aren’t 
financially suc- 
cessful, most 
miss their 
intended 
ship dates, 
and 
most 
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have significant bugs and require a 
patch (or three). Within a viciously 
competitive environment, as an indus- 
try we must find a way to lower some 
of the risks involved with building 
game software. 

Not all risks are controllable while 
developing game software. You can 
never be sure if consumers will like 
what you offer (though there are 
methodologies for reducing this risk, 
too). You never know when Microsoft 
might change the operating system 
components. Sometimes, a competitive 
product is unexpectedly introduced, 
and you must react to it. Management 
often will dictate large numbers of 
unexpected changes. 

Given this chaotic environment, it’s 
important to acknowledge and manage 
the risks that are under your control. 
For risks that you don’t control, but are 
within your sphere of influence, you 
must make agreements with all parties 
so that no surprises occur without 
renegotiation. This gives you a man- 
ageable baseline with which to start, so 
that you can react with more clarity 
and confidence to the truly uncontrol- 
lable risks. 


How We Approached an 
Engineering Discipline 


- ecause Our company is in a busi- 
ness where products must be 
maintained for several years, we felt 
we had to make a radical change to 
compete successfully. We first exam- 
ined the various training opportunities 
available. We looked at several soft- 
ware development methodologies used 
by other industries, including the SEI 
Capability Maturity Model (CMM), 
ISO 9000, SPICE (Software Process 
Improvement Capability and 
dEtermination), and others. We 
found that all these method- 
ologies contained elements 
useful to our goal of insti- 
tuting engineering disci- 
pline. They also con- 
tained elements 
that could stifle 
creativity and 
ignored the im- 
portance of hav- 
ing fun software in 
favor of schedule 
predictability. 


http://www.gdmag.com 








grsscs 























NAMING CONVENTIONS 


Basic Types 


FUNCTIONS 


FILE LAYOUT AND ORGANIZATION 








CONGIONTS 222-0 <enamndanrieemenon 
HUNGARIAN NOTATION 0+ 400000000 e 


oeeeeveeeeeeeeeee ee eee 
eeeeeeveeeeeeeeeeeeeee 


MOCHIONS cane tance eee 
PROMIDIOS ocaedas dans eeseceene acs 
WANIAELE tiveen weir aa eee aNy wae 
GIG0G) VGNODIES cy xcescecenamune 
SiC VaNODIGS ««sw0tncenenane 
LOCGI VGHGUICS as canraeeaetad des 
C¥t SPCCHICRUIES sc 0sxeeckcaxens 
TIPES nxdsnacnetuneereeresemeens 


oeeeee eee ee eee eee eee 
oeoeeee eee ee eee eee eee 
oeoee eee eee ee ee eee eee 
eoeeeeeee eee eee eee eee 
oeoeeee eee eee eee ee eee 
oeoeerere eee eee ee ee eens 
over eee eee eee eee ewes 
oeeerere eee eee ee eee eee 
oeoeeee eee eee ee eee eee 


COGS «+ idee ec senee ce erersrenns 
ORY PVIGS: sswnanenmensss wean 


Pe ocomsaeeamausoaksawaee 
PRs er Wiad ou ote RN 


eeeeeveeeeeeeeeeeeeee 
eoeeneeeeeeeeeeeeee ee 


COPYRIGHT NOTICE xsccccsansvaenes 
COMMENTS 2006800648403 serexwees 
Prototype Comment Rules ........ 
Function Comment Block ......... 
Variable Comment Rules ......... 
Type Comment Rules ............ 





VN 


Kesmai Studios Programming Standards 
Table of Contents Version 1.0 (April 23, 1997) 


CORSIGNT COMIMEGRT RUNES «dc dremeennaeuane dere stevia 
FIEADERS x.cavccavsen 


CopING RULES 


No Magic Numbers 


Return Values 


Kesmai’s programming standards table of contents. 





Because no current methodology 
that we investigated suited our needs 
completely, we decided to invest in 
training our personnel in the SEI’s 
CMM methodology, with the proviso 
that we didn’t want to follow their 
developmental model exactly. We sent 
80 percent of our development and QA 
personnel to this training. We also 
investigated several project-manage- 
ment training programs. After one 
course given by the Learning Tree 
Company, two of our producers came 
back very excited and charged up. They 
really liked the particular instructor, so 
we contracted that instructor to give a 
one week class on project management 
to our entire development staff. 

At this point, we had most of our 
personnel “speaking the same lan- 
guage” and interested in improving our 
software development methodologies. 
This was a key step. This kind of 
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change in mindset cannot be mandat- 
ed from management; it must be a 
joint effort between developers and 
management to work. We started our 
process of instituting an engineering 
discipline with three initiatives: pro- 
gramming standards, the peer review 
process, and the software process work- 
ing group. 

PROGRAMMING STANDARDS. We quickly 
devised a good set of programming 
standards that the entire development 
staff could buy into, although there 
was some debate as to how these stan- 
dards would be instituted. These stan- 
dards were created in reaction to the 
difficulty we experienced in maintain- 
ing our legacy code. While these new 
standards didn’t help us maintain our 
old code, they made sure we wouldn’t 
perpetuate poor coding practices in our 
new games. Thus, our payoff will come 
when we hire new people to maintain 
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games in the future. The products that 
our developers will maintain in the 
future will have a defined coding style 
and methods. The table of contents for 
our programming standards, which 
illustrates the elements that we 
believed were important to standard- 
ize, are Shown in Figure 1. 

PEER REVIEW PROCESS. The definition of 
the term “peer review” is encapsulated 
in this quote from the SEI Capability 
Maturity Model: “The purpose of peer 
reviews is to remove defects from the 
software work products early and effi- 
ciently. An important corollary effect is 
to develop a better understanding of 
the software work products and of 
defects that might be prevented.” Peer 
reviews, in this context, have no 
impact on personnel evaluation at all; 
they’re simply a method of process 
improvement — never a methodology 
for placing blame. This peer review 
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Games produced, financed or initiated by a publisher are not eligible. 
However, games produced, financed and initiated by an independent 
developer (defined as any individual or company not currently receiving 
funding from a publisher}, and games that were purchased by a 
publisher after completion, are eligible. 


There are two Festival categories: 
Completed Games and Unfinished Games. 


@ Completed games are ready to be played in their entirety, and will 
only be judged against other completed games, Eligible completed 


games may not have been released commercially before January : 3 
1997, and must be completed by January 1, 1999. 


@ Unfinished games must be playable, and have at least one complete 
level to demonstrate. Unfinished games will 3 be eae eae 
other unfinished games. 


The Festival will not assume any responsibility for noddiococine or 
secrecy violations for its entrants, and the festival may disclose and/or. 
exhibit any or all submissions. The Festival is open to the public, andi tt 
= se be assumed that all Submissions = be seen by mer 


Selected entries must be shipped prepaid, insured, packed in proper Bes 


containers and received at the GDC indie Festival office no- later than 


January 15, 1999. 


The jury of the GDC Independent Game Festival will comprise 
distinguished individuals from the field of game development, serving 
as judges of the Competition. The jury wilt judge games and select 


winners in five categories: — 


~ 1 Grand Prize 

2 Artistic Award 

3 AudioAward 

4 Game Design Award 

z Technical hee panies , 


| conference Hendess wil be given at the Festival. 
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a This is a 1,500 word product covering only the following issues: 
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High Concept: The overall game concept . 
Game Play: The core game mechanics. 
Conflict: What creates the tension that motivates players? 
Multiplayer Aspects: What makes this a massively multi- 
player game? 
Spend your 1500 words however you wish to cover those 
four core issues. In many cases, Conflict and Multiplayer 
1 Aspects will be evident in the description of Game Play. If the 
| game itself is evident, as well as its qualities as a multiplayer 
| game and its ability to motivate folks to play, your proposal 
will have met the requirement, and done so in able fashion. 


For further details regarding Game Play, Conflict, and 
Multiplayer Aspects, read CONCEPT_GUIDE.DOC. 
Submission “Help Desk” 

Help is available from the Editorial Committee for all sub- 
mitters who wish it, prior to their proposal submissions. This 
way, you can get feedback prior to sending it in. If you want 
someone on the committee to go over your proposal with 
you, just send a request via internal e-mail to Jonathan. He 
will, in turn, match you up with someone suited to the type of 
game you wish to create. 

Deadline and Delivery 
All submissions are due by 5:00PM on Friday, 
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Concept document guideline. 








above, the Requirements Baseline contains 
the following elements: 


Overview: A one- or two-page description of 


the game, sufficient to give the reader a 
sense of its game play and scope. This 
would be very similar in format to the Initial 
Concept Document, except for the omission 
of any features removed through the Initial 
Concept approval process. 


Key Requirements Summary: A one-page 
s condensation of the most important 
requirements drawn from the total known 
set. This is intended to provide a high- 

— level, balanced perspective on the most 

_ important goals to be achieved by the pro- 

ject, uncluttered by the detail necessary in 

the departmental breakdowns. 


Requirements Breakdown: A department- 
by-department itemization of all known and 


accepted requirements. This should contain 


documented, institutionalized requirements 
as well as project-specific requirements, as 
identified and submitted by the depart- 
ment’s representative. Sources include, but 
are not limited to, published documents, e- 
mails, meeting minutes, and phone calls. 
Change Log: Once the RB has been placed 
under revision control, any changes to the 
document should be noted in the change 
log. Each entry should contain (at a mini- 
mum) a description, date, and reason for 


__ the change. 
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process only took a few weeks to ham- 
mer out, and is now embraced by our 
developers. Reviews go on almost every 
week in our studio. The primary value 
of peer reviews is in finding problems 
and potential problems long before 
they would normally be found in the 
testing stage. A less obvious but equally 
powerful benefit is that all participants 
in the peer review process learn to 
avoid both common and subtle errors 
in their own work. We encountered 
some resistance to peer reviews, 
because there was concern that man- 
agement would use these reviews to 
rate our developers. Once it was clear 
that this was not the case though, our 
developers embraced the process. 

Our first peer reviews found signifi- 
cant problems that had defied other 
debugging methods, and every peer 
review we've conducted so far has 
found and corrected problems. As our 
people gain more experience with peer 
reviews, they’re uncovering problems 
earlier in the development process — 
bugs might otherwise have taken weeks 
of debugging had they still existed 
when the game was in beta testing. 

When used effectively, peer reviews 
are a powerful tool to improve both the 
quality and the effectiveness of your 
development staff. The relative cost of 
finding and correcting errors early in 
the development of a title is incredibly 
low compared to trying to correct bugs 
when you're about to ship. If you don’t 
already conduct peer reviews, I recom- 
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Once the Requirements 
Baseline (RB) is created, 
it must be approved by all 
involved departments 
before development may 
proceed. 
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Here, the RB document is created. 
This may involve many iterative 
versions of the doument, and will 
also require meetings with other 
Kesmai departments to define the 
requirements of those departments. 
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Approved? 


Requirements Baseline initiation and revision process. 





mend starting today. 

SOFTWARE PROCESS WORKING GrRouP. [he 
Software Process Working Group was 
responsible for creating and delivering 
a number of items, which are consoli- 
dated into a document called the 


Kesmai Studios Software Process Guide. 


The Kesmai Studios life cycle has five 
phases: 
1. Concept 
2. Requirements Definition 
3. Design 
4. Implementation 
5S. Maintenance 

This list is just one of many ways to 
define a product life cycle. Your com- 
pany may have different phases and 
terminology. There is no one true way, 
as each company must define its life 
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cycle to match its business and market 
requirements. We picked some new 
projects to test these processes as we 
created them. | will use a fictional 
product called BAZOOKA BUNNY to illus- 
trate some of these phases. 

Concept. We created a document to 
describe what made up a valid game 
concept for our product life cycle. It’s 
used to select what products are built 
in our studio. Because our develop- 
ment focus is massively multiplayer 
games, this quality is heavily empha- 
sized within the concept document 
guideline, shown in Figure 2. 

For the purposes of our development 
life cycle and internal selection 
processes, we wanted our concepts to 
be very compact; other companies 
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Lessons 
Learned 








might want much more volume and 
detail. A committee made up of mem- 
bers of the studio approves concepts 
for further development. 

REQUIREMENTS DEFINITION. The require- 
ments definition phase is embodied by 
two documents, the Requirements 
Baseline and The Plan (see the sidebar, 
“The Requirements Baseline”). Our 
Requirements Baseline initiation and 
revision process is shown in Figure 3. 
Notice that there is a defined process 
for creating a Requirements Baseline, as 
well as for modifying the process of 
creating the Requirements Baseline (in 
the event that we decide that the 
process isn’t optimal). All processes 
used must have feedback mechanisms 
so that they can continuously improve 


1998 GAME DEVELOPER 


js 














GAME DEVELOPER 


eee 


aeee 
EEPEEPP ES EST rrr rT rrr’ 


— Ss 


Sse se 









a @ 
ae ee ee 


BAZOOKA BUNNY — SAMPLE REQUIREMENTS 


Baseline Revision 1.4, September 20, 1997 


Prepared by: John Robinson, Will Robinson, Doctor Smith 


Overview 
BAZOOKA BUNNY is multiplayer action 

game in which poor, defenseless, and 

slow-witted computer programmers (the 

players), armed only with a handful of 

light, armor-piercing rocket launchers (and 

a few miniguns) venture forth into the 

cruel, harsh meadow to do battle with 

fiendishly clever rabbits. Terror ensues 

when the players’ repeated saturation fire 

into the underbrush fails to produce the 

anticipated scurrying about, and fratricide 

levels begin to reach... (snipped for brevity) 

..and in a furious frenzy smash the albino 

queen into red and white pulpy bits with 

their shovels, thus ending the hideous 

threat. 

Summary of Key Requirements 

¢ Supports up to 3,000 players competing 
in separate arenas (meadows) of up to 
100 players each. 

e Plays on a Windows 95 machine with 
DirectX 5.0 or greater. 

e Plays on a Pentium 200MHz or better 
with 3D accelerator required. 

e Requires 100MB hard drive space and at 
least 32MB of RAM. 

e Plays with keyboard only, mouse/key- 
board, and joystick/keyboard. 

e Uses an isometric, third-person view. 

e Uses real 3D, not prerendered sprites, 
voxels, or raycasting. 

e Uses Visual C/C++ for FE development. 


Requirements Breakdown 
Project 


e Supports up to 3,000 players competing 
in separate arenas (meadows) of up to 
100 players each. 

e Uses an isometric, third-person view. 

e Uses real 3D, not prerendered sprites, 
voxels, or raycasting. 

e Plays with keyboard only, mouse/key- 
board, and joystick/keyboard. 

e Each character has 24 distinct anima- 
tions, 4 unique to each class. 

¢ Each meadow is approximately 10 kilo- 
meters square. 

Kesmai Studios 


e Plays on a Windows 95 machine with 
DirectX 5.0 or greater. 

e Plays on a Pentium 200MHz or better 
with 3D accelerator required. 


Sample Requirements Baseline 
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e Requires 100MB hard drive space and at 
least 32MB of RAM. 

e Uses Creator to produce objects 
and terrain. 

e Uses Visual C/C++ for FE development. 

e Uses a revision control system. 

¢ Host development environment is HP/UX 
on HP hardware. 

Creative Services 

e Need to negotiate a staged production 
schedule for art, sound, and editorial, 
taking into account the software sched- 
ule, the interdependency of each piece, 
and the quantity to be produced. 

¢ Need to be informed of the various tech- 
nologies that will be used within the pro- 
ject to ensure that CS personnel are ade- 
quately trained and necessary tools are 
available by the work start date. 

Marketing 


e Need sample art and sounds for web 
pages three months prior to scheduled 
release. 

e Need character class descriptions and 
updated feature list three months prior 
to scheduled release. 

¢ Need .AVI of game play one month prior 
to scheduled release. 


Product Support 


e A list of error messages that might be 
conveyed to the user in the course of 
game operation and what actions to take 
to alleviate the problem. Need to havea 
way to enter the game when it’s full. 

e Need to have a way to find out player 
info using the player’s in-game handle 
asa key. 

¢ Need to be able to eject a player who is 
violating TOS agreement while playing. 

Operations/Tools 


¢ Need to have a list of all game processes, 
with sample configuration files, an expla- 
nation of what they do, and any special 
requirements they may have. 

e Need to have detailed installation 
instructions for the host processes. 

e Need a coordination meeting to deter- 
mine the ARIES implications and feature 
schedule. 


Product Acceptance 


¢ Need a software test plan at least two 
weeks prior to the scheduled start of 


acceptance testing. 

¢ Need to have FE install at least two days 
before the scheduled start of acceptance 
testing for every release. 

e Need to have a beta test host delivered at 
least three days prior to the scheduled 
start of acceptance testing for every 
release. 

Executive Committee 

e The product must run on AOL and 
GameStorm. 

e The product must be available by Q1, 
1999. 

Third-Party Support 


¢ The game should avoid liberal use of the 
word “rabbit,” because one of our other 
games already supports a familiar theme 
of blasting rabbits with bazookas. 
Referring to the critters as “bunnies” or 
“fuzzies” should deflect from any simi- 
larity. 

Community Support 


¢ The game must emit a player scoreboard 
in a negotiated format for display on the 
Web. 

¢ The game must support a control query 
returning player information in the game 
context for display on the Web. 

e The game must support a “news ticker” 
giving descriptions of what’s happening 
in the game to be displayed in real-time 
on the Web. 

Help Desk 


e A list of error messages that might be 
conveyed to the user in the course of 
game operation and what actions to take 
to alleviate the problem. 

Publishing 

e The project must deliver installation 
packages in the format required by the 
GameStorm client. 


Change Log 

11/3/97: Added rabbit to bunny word 
replacement throughout the design doc- 
umentation at the request of third-party 
support. 

11/25/97: Changed number of animations 
from 12 to 24 after some hashing out of 
the initial paper design with the project 
team. 
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based on the input from the teams that 
use the process. A simplified example 
of a Requirements Baseline for our fic- 
tional BAZOOKA BUNNY product is 
shown in Figure 4. 

You may have noticed the large 
number of departments that are refer- 
enced in the Requirements Baseline. 
Involving so many people at this step 
is initially time consuming, but it gets 
all the key departments involved and 
gives them the ability to give 
their input about the prod- “a 
uct. It also secures their 





agreement that these are | 3 


their requirements for the 

product. Any future 

changes result in the cre- 
ation of a new agreement, and all the 
parties must re-approve the changes. 

While this applies friction to the 

process of making changes to the pro- 

ject, it does discourage people from 
suggesting frivolous changes. 

Additionally, important changes are 

allowed to move forward with a con- 

sensus from the key parties involved. 

Once these requirements are formal- 

ized for the first product, most of 

these requirements are reused for fol- 
low-on products. 

The Plan document, alluded to in 
Figure 3, outlines the general path 
that development will follow and 
describes additional elements beyond 
the key requirements listed in the 
Requirements Baseline. It also outlines 
all project deliverables, such as a ter- 
rain editor, mission editor, manuals, 
and so on. The Plan is a living docu- 
ment that changes as the product 
moves from the requirements phase 
through the design and implementa- 
tion phases. The Plan demonstrates to 
management that the team knows 
what they are doing and how they 
will go about getting it done. 
Specifically, The Plan includes the fol- 
lowing items : 

e The vision and goal of the project 
(approximately one or two para- 
graphs). 

e The list of reference materials. 

e Project organization (management, 
responsibilities, work products, pro- 
cess model). 

e Risk management. 

e Project plan (deliverables, major mile- 
stones, staffing, and organization). 
Every project develops a large num- 

ber of work products during the course 
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of the project. Some of these work 
products are deliverables that are given 
to people outside of the project team, 
such as the software itself, user manu- 
al(s), and test plans. Other work prod- 
ucts are mostly for internal use, such as 
analysis and design documents, source 
code, and build procedures. The Plan 
document outlines all of the work 
products that will be created and gives 
a rough timetable and order of deliv- 
ery. [he intended target audience for 
each deliverable is also defined. 

In order to prevent changes from 

completely derailing a project 

during development, an effective 
_ change control plan must be 
established early in the project 
cycle. This process is written into The 
Plan so that change control procedures 
are established from the very begin- 
ning and are used on every baselined 
work product. “‘%, 

We define high-level project mile- 
stones in The Plan and leave the 
detailed scheduling information in a 
separate document. Milestone target. 
dates are initially estimated based on — 
the project scope and budget. As the 
development progresses and the sched- 
ule becomes more accurate, these mile- 
stone dates are changed within The 
Plan. As such, we always keep The Plan 
up to date. 

Design. [he design of the product 
flows from the requirements defini- 
tion. The design is made up of a series 
of stages that are contained in four 
main documents under our definition 
of this phase (Figure 5). These docu- 
ments are the Software Design Speci- 
fication, the Software Project Plan, the 
External Resource Specification, and 
an initial Software Testing Plan. The 
Software Design Specification, in turn, 
is composed of three subphases: cre- 
ative design, technical design, and 
resource analysis. 

The creative design subphase is 
made up of a series of four documents, 
titled Overview, Thematic Content, 
Interface Storyboards and Prototypes, 
and Game Mechanics. The combina- 
tion of these documents describes 
how the game will look, feel, and 
play. In addition, the initial External 
Resource Specification is created dur- 
ing the creative design phase, which 
lists all the art, sounds, and other 
externally created elements necessary 
for the product. 
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The technical design subphase is 
made up of a series of three documents: 
Requirements Analysis, System 
Architecture, and Module Specification. 

Finally, the resource analysis sub- 
phase is where The Schedule, the final 
External Resource Specification, and 
the initial Software Test Plan are all 
created. The Software Project Plan is 
simply our schedule for the game’s 
design and implementation, and it’s a 
fairly common document to most pro- 
jects. The Schedule is based upon the 
detail provided by the combination of 
the Software Design Specification and 
the External Resource Specification. 
The Software Testing Plan, which is 
initially created in this phase, is a 
roadmap for our product testing group 
to use to validate the functionality of 
the product. 

IMPLEMENTATION. Once the design phase 
is complete and approved, the project 
moves into the implementation phase. 
The implementation phase is divided 
into the construction subphase and 
the release-and-refine subphase. Most 
of our larger products use a staged 
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~ delivery process, so we construct mul- 


tiple stages and then move the final 
stage into a release-and-refine sub- 
phase. oftware Testing Plan, 
which began in the Design phase, is 
completed during the construction 
subphase. This is a complete testing 
plan for the product describing the 
methodology and elements of a proper 
test of the product. 

The majority of the construction 
subphase is spent doing the traditional 
programming, integrating, and testing 
of the product’s modules as it moves 
towards completion. In each stage of 
the construction subphase, the 
Software Testing Plan is being incre- 
mentally completed. 

Once a project has reached the 
alpha release milestone, it moves into 
the release-and-refine subphase 
(Figure 6). In this subphase, the focus 
is not on developing new features, but 
on testing, fixing bugs, and complet- 
ing the product for the production 
release to players. During the alpha 
release stage, it’s inevitable that fea- 
tures will be changed or added, but 
the focus in the release-and-refine 
subphase is on stability and fine tun- 
ing. This is the last development 
phase of a project, and it consists of 
four key stages: 
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Creative Design is composed of four activities: Overview, Thematic 
Content, Interface Description, and Game Mechnaics. Each of these 
progresses more or less in parallel during this phase. 

NOTE: It is expected that some amount of technical work, such as technology 


assessments and prototyping, will occur during the Creative Design phase. 
| NOTE: Its is also expected that the list portion of the ERS will be completed 
during this phase, although the final estimation is not required until the 
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FIGURE 5. Design process flow. 


1. Alpha Release 

2. Closed Beta Release 

3. Open Beta Release 

4. Production Release 

MAINTENANCE. Once a game achieves 
good stability and it’s at the gold-mas- 
ter stage, it moves out of development 
and into maintenance and enhance- 
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Resource Analysis phase. 






EE 


“Complete” in all 
decision boxes indicates 
that it is done and has 
been reviewed and 





approved per the 


Software Process Guide 





Creative 
Accepted? >Yes Design Complete? 
Yes 
On 
No Schedule? No 


Technical Design is composed of four activities. These are: 
Requirements Analysis, System Overview (Architecture), Module 
Identification, and Module Specification. These activities are 


performed iteratively throughout the phase. 


Yes 


Technical 


4 
Design Complete? 
On 
No Schedule? No 


Proposed Changes 
to Design Process 


Lessons 
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ment. The project has been complet- 
ed, and although work will likely con- 
tinue throughout the life of our mas- 
sively multiplayer games, it will be at 
a maintenance level. Most likely, 
maintenance will be handled by dif- 
ferent personnel than the original 
development team. 
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Problems Faced at Kesmai 


L ack of management buy-in was not 
a problem we had, but it might be 
one that you will encounter. Without 
the commitment of upper manage- 
ment to instituting engineering disci- 
pline through process improvement, 
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Approved? 


Implementation flow. 


it’s almost impossible to accomplish 
any real changes. The process of mak- 
ing significant changes to production 
methods takes the commitment of 
everyone involved, and if management 
changes directions in mid-stream, all 
benefits can be lost. Our management 
and our developers devoted the time 
and effort that it required. 

Our first significant problem was 
coming up with a vocabulary for every- 
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which details the activities 
of that particular stage. 
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Each release of the software is a planned (scheduled) event, 
even if the software is not released to the public at this point. 
The "Release and Refine Phase" details the actual release 


procedures and requirements. 


Once the entire implementation is complete, the project can 
conclude. Typically, this is when the software would be 
transitioned into the "Maintenance and Enhancement 
Phase" of the software process. 


Proposed Changes 
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one to use. Common terms meant dif- 
ferent things to different people. This 
problem was primarily a training prob- 
lem, and sending the majority of our 
people to SEI CMM training, combined 
with in-house project management 
training, largely overcame this prob- 
lem. However, due to the complexity 
of the processes involved with develop- 
ing games, and the number of depart- 
ments involved outside of develop- 
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ment who don’t share our special 
vocabulary, we still find the vocabulary 
of disciplined engineering problematic. 
The next large problem that we 
encountered was the team’s impatience 
to start working (programming) on a 
new project. Planning a new game 
down to the final details before writing 
a line of code (other than necessary 
“proof of concept” prototyping) is very 
counterintuitive to most game pro- 
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grammers. Discipline came into play 
here, as both management and the 
development staff kept focused on the 
new processes even when tempted to 
follow old patterns of development. 

Getting all other departments — 
such as our publishing, product testing, 
marketing, and operations depart- 
ments — to cooperate with our new 
processes was also a challenge. We 
overcame many of these problems by 
including these departments in the cre- 
ation of our processes. A grassroots, 
organization-wide commitment to 
process improvement really made a dif- 
ference for us in this area, but there are 
always holdouts who prefer the tradi- 
tional methods despite potential bene- 
fits. You need to have the key people in 
the departments you work with educat- 
ed and on-board with your planned 
improvements. 

The sheer amount of paperwork and 
process involved is daunting, particu- 
larly for groups used to a seat-of-the- 
pants development process. I’m sure 


many people reading this article won- — 


der how any “real” work gets done ~ 
with all the paperwork involved. We 
discovered that all this paperwork 
inevitably gets done, either by a prede- 
fined plan or as an emergency later in 
the project. In our experience, most 
slippage in schedules is driven by ele- 
ments that weren’t explicitly defined at 
the beginning of a project. Our process 
improvement effort simply acknowl- 
edged all the known requirements at 
the beginning of a project rather than 
in the midst of development when it 
adds to both schedule and cost. 






e biggest benefit that we’ve real- 
ized so far has been improved 
morale. Our development staff is 
excited to be involved in a process 
that is progressive and has the oppor- 
tunity to take our group to a high 
level of effectiveness. There has been 
unanimous participation in the cre- 
ation of and compliance with the 
new processes. The 
process changes are 
showing results, and 
developers feel more 

in control of the pro- 
ject. Mid-stream 
changes in projects still 
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occur, but because projects are now 
less chaotic, dealing with these 
changes is much more manageable. 

Getting the project baseline 
requirements written down 
and agreed to by all 
departments was a 
major benefit. When 
requirements change 
(as they often do), it puts 
you in a position to document 
the change and inform all parties of 
the effect it will have on the schedule. 
It allows cost and schedule trade-offs 
to be done rationally and reduces 
needless feature creep. Thinking about 
and documenting these requirements 
has headed off innumerable future 
problems. — 

Having a full design, a technical 
design, prototyping technology, and 
solid estimates of programming tasks at 
our disposal allows us to plan the cre- 
ation of the art, sound, and editorial 


resources better. This has helped 
~ reduce the false starts and rework of 


these elements, in comparison to previ- 
ous projects. 

Management has a much higher 
confidence in the schedules of the 
products, and a much better idea of 
where the product is relative to the 
projected completion date. The actual 
schedule exists only after the technical 
design is completed and approved. We 
only use broad ranges of time prior to 
the completion of this phase, which 


requires a high degree of trust between 


management and development teams. — 


Future Expectations 


W e expect that as our personnel 
gain more familiarity with the 
processes, we will see further improve- 
ments in productivity. We also believe 
that we’ll reap benefits in our mainte- 
nance efforts once our products move 
to that stage. Our standards will dra- 
matically reduce the time that it takes 
to train new programmers to 
~maintain legacy products. 
! The time that it takes to find 
bugs and make additions to 
these legacy games will be sig- 
nificantly reduced. As we move 
our current set of products into pro- 
duction, we expect the quantity and 
severity of found bugs to be much 
lower than was previously the case. 
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The combination of completely plan- 
ning the product prior to implementa- 
tion, peer reviews of key soft- 
ware modules, and test 
plans created by the team 
should continue to raise the 
quality of our software. 
Finally, our time-to-market 
should decrease as our software 
development process improves 
and our teams become accustomed to 
the new procedures. 

It has been exciting to move 
towards building game software under 
our new model. Our new procedures 
allow our developers to be more effec- 
tive in a normal workday, and 
although the occasional crunch still 
occurs, we no longer face grueling, 
continuous 16-hour days during a pro- 
ject death march. We have already 
seen a difference in our shop, with 
people rising to new levels of contri- 
bution and productivity simply 
because the environment allows it. 
The standard sweatshop atmosphere 
of game development only allowed 
the “coding cowboys” to be heroes. 
Now, we have teams entirely staffed 
with heroes, doing great work without 
having to resort to heroics. Being 
involved with fostering this move to 
engineering discipline is the most sig- 
nificant effort that I’ve been involved 
with in my 20 years of creating games. 
I believe it has the potential to take 
much of the chaos and uncertainty 
ut of development and let us focus 
creating great game play in our 
ture titles. Hf 
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arlier this year, a small hunting simula- 


tion called DEER HUNTER shocked the 







industry by rocketing to the top of the 


sales charts for three months. Presently, 


it’s still selling well and shows every 


indication of continued good sales. 


While most hardcore game players stick up their noses at 
such value-priced games, the truth is that there’s still a huge 
untapped market of computer users who do little with their 
PCs but write letters, send e-mail, and play solitaire. Death 
rays and world conquest hold very little interest for them, 
and they’re still waiting for a game they’ll enjoy playing. 


snidely thinking that there is no strategy to swigging down 


D “ » Although I’m not inclined to debate the merits of games 
such as DEER HUNTER, let me at least point out a few facts 
iq 7 A U N T ¢ Ss regarding the game that might help to tip the balance of 
opinion in its favor. 
e DEER HUNTER was the first game to attempt seriously to 
r Sd ( od oS 7 t simulate the strategies involved in deer hunting. If you’re 
a beer and storming through the woods after a buck while 
blasting away with your shotgun, then you have no real 
if eve i 0 mm e nr t knowledge of hunting on which to base a valid opinion. 
Before I sound too sanctimonious, I should point out that 
before I worked on DEER HUNTER, I had little knowledge of 
C hunting myself, and shared many of the same prejudices. 
y C e DEER HUNTER is a value-priced game. It costs only $20 and 
includes $20 worth of value. Many people tend to compare 
this product against games costing two to three times as 
much, with budgets often 10 times or more what we had 
by James Boer to work with. DéER HUNTER’ total development cost was 
around $75,000. Remember to compare apples to apples. 
DEER HUNTER was targeted specifically at non-enthusiast 
game players. This meant that both controls and game play 
were kept as simple as possible. This wasn’t only expedient; 
it was a requirement determined at the outset of the project. 
e DEER HUNTER was developed from the ground up by three 
programmers (one was a college intern) and a part-time 
artist in less than three months. 


It’s this last point that I really want to focus on, because it 
is one of the more interesting aspects of the game, the 


| James Boer is a programmer, game designer, and musician. 
During the development of DEER HUNTER, ROCKY MOUNTAIN 
TROPHY HUNTER, and PRO BASS FISHING, he acted as designer, 


_ programmer, art coordinator, sound designer, and voice-talent. 
He currently resides in Seattle, Wash., and is working at 
WizBang Software Productions. He can be reached at 

| jbsys@csi.com. 
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remarkable sales notwithstanding. How the game sold after 
it shipped was a shock to everyone, including us, but the 
development cycle was something that was controllable. 

At this point you may be saying to yourself, “So what if a 
small game such as this was written quickly? The product 
I’m working on is much more complex, has many more fea- 
tures, yada, yada.” 

This could very well be true. However, many of the lessons 
learned in a compact development cycle can be applied to 
any sort of game development project. I’ve had the opportu- 
nity to analyze and fine-tune our development process 
through five games in one year. Even if a project is expected 
to require a year and a half to complete, the same strategies 
can be applied to individual milestones within the project, 
or even to project components over a much longer period. 
The techniques don’t necessarily have to be used to speed up 
development, either. They can just as well be used to get 
more from your existing timelines. 

In this article, | outline some of the salient aspects of our 
development cycle. Some of the points are undoubtedly 
common sense, but all too often common sense gets ignored 
in the face of tradition or other external pressures. Other 
points, however, fly in the face of conventional design 
approaches. While it’s true that not every project could or 
should attempt to utilize some of these principles, the fact 
remains that, using these techniques, Sunstorm rapidly pro- 
duced hit after hit in quick succession. 


Lesson 1: Don't Over-Design 


H t’s better to keep the game plan simple and understand- 
able. You don’t necessarily have to code the entire game 
on paper. I’ve found that the most important aspect of the 
initial design lies in clearly delegating responsibilities for the 
project components. Instead of delving into the inner work- 
ings of how individual components are going to work, focus 
on how the major components are going to work together. 
Again, these don’t necessarily have to be completely set in 
stone. Rather, let the programmers who are dealing with 
those components work with each other to figure out how 
their components should communicate. Because they are 
the only ones the problem affects, it makes sense that they 
should facilitate the solution, both in design and in code. As 
long as their solution is solid and well documented, there’s 
no reason to involve other members of the team in the deci- 
sion process. Planning by committee in cases such as this is 
both unnecessary and inefficient. 

There’s one caveat to this technique. One instance in 
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which it does not pay to skimp on design is interface design. 
Over the course of three projects, I’ve learned that time 
spent carefully mocking up all the game screens helps 
tremendously as a reference for both the programmers and 
the artists during all phases of development. 

Note that I’m not talking about a complete graphical mock- 
up. I’m referring to a functional mock-up. I use CorelDraw to 
roughly position all elements on the various screens. I print 
each screen on a separate page. | label all buttons and explain 
their functions. | make no attempt to create an aesthetically 
pleasing screen. The artist’s job is to arrange and beautify the 
various controls except where noted on the document. 

A solid interface design not only helps to solidify the flow 
of the game, it also frees those responsible for its implemen- 
tation to begin coding and illustrating while the finer points 
of game play continue to be debated. As the game evolves, 
this document is updated to reflect the latest changes. 


(47 


Lesson 2: Dont Be Afraid to 
Design Dynamically and in Parallel 


he original idea for DEER HUNTER was actually simpler 

than what ended up on store shelves. I joined Sunstorm 
in May of 1997 with a rough idea of what I’d be working on, 
but no real knowledge of hunting. My first assignment was 
to design a deer hunting game. You might imagine how 
thrilled I was at the prospect of designing a game based on a 
“sport” that consists mostly of sitting and walking around in 
the woods for hours on end, waiting for a passive animal to 
show up so you can shoot it. 

The initial game idea wasn’t much more than many of the 
other hunting titles seen previously — that is, blasting a deer 
when it happened to meander across your path. As develop- 
ment progressed and I became more knowledgeable of the 
intricacies of hunting and stalking deer, I realized that we 
could, with a slight change of focus, turn the game from an 
arcade gallery into a simulation with the addition of an over- 
head map view and a dynamic scene generator. The biggest 
reason for DEER HUNTER’S success was that we were the first 
company to make a serious attempt at creating a realistic sim- 
ulation. Our dynamic development process allowed us to shift 
focus enough in mid-development to capture this market. 

Although some projects have failed due to the lack of a 
strong design, we found that taking a flexible approach to 
game design worked in our case, and it might be worth con- 
sidering on your next project. I’m not advocating that you 
turn your 3D shooter into a real-time strategy game halfway 
through development. Rather, try prioritizing design elements 
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FIGURE 1. DeER HunTER’s task schedule. 


by their expected completion date and 
finishing designing these elements first. 

For instance, if the user interface is 
rather straightforward but the game 
play still needs some work, let a pro- 
grammer and an artist start moving 
forward on this aspect of the project 
while others hammer out the details of 
game play. This is an example of 
designing in parallel with the project. 
Because the components have a logical 
separation from other aspects of the 
design, this process makes perfect sense 
and avoids down time. 

Likewise, in-house development 
tools can often be started long before 
other portions of a game are complet- 
ed. It may even be a requirement. (For 
more on this point, see Game 
Developer's October 1998 Postmortem 
of Monolith’s SHOGO to see what can 
happen if custom tools aren’t given 
enough attention early in the develop- 
ment process.) If design issues are still 
up in the air, make sure the tool pro- 
grammer makes allowances for addi- 
tional functionality that might be 
added. The time wasted in having to 
change a file format is more than made 
up for by the fact that the programmer 
didn’t have to wait another month for 
the design specifications to be finished. 

Dynamic design — altering the 
design during development — might 
also bear consideration. Again, use 
some common sense — I’m not talking 
about changing the entire course of a 
project. We found that it doesn’t pay to 
try to anticipate every problem that 
may come up during the course of 
development. Instead, we set goals to 
attain and expected both the artists and 
programmers to be creative enough to 
reach those goals on their own. Many 
times during the course of a project, we 
thought of a better way to achieve the 
goal that we’d set out to reach. One of 
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the more interesting effects in the game 
is the zoom lens on the rifle scope and 
binoculars. Although the design of this 
effect was originally intended to bea 
simple pixel doubling, I realized that we 
could make the effect much more con- 
vincing if we could preserve the sprites’ 
highest level of detail by using a tech- 
nique we hadn’t thought of earlier. By 
focusing on the goal instead of the 
process or the details, those of us work- 
ing on the project could enhance the 
game significantly while still maintain- 
ing the original schedule. 


Lesson 3: Smart Scheduling 


i brought up the issue of scheduling 
when discussing parallel design, but 
it warrants more attention. Intelligent 
scheduling means planning to com- 
plete components so that you minimize 
your reliance upon incomplete code; 
this was one aspect of our development 
process that allowed us to get DEER 
HUNTER out the door fairly rapidly. 

For instance, Figure 1 shows the task 
schedule from early in the DEER HUNTER 
project. Mike Root, our project leader 
and lead programmer, was responsible 
for creating and maintaining the gener- 
al framework of the game, as well as 
other items such as creating the 
weapons and building the sound 
libraries. He also built a resource editor 
that helped us manage all the game art- 
work. Nate Terpstra, our trusty intern, 
worked on the DirectDraw graphics 
libraries and user interface controls. My 
responsibilities included game design, 
artificial intelligence and deer behavior, 
map creation, and scene generation. 

You can see in Figure 1 how both my 
game design and AI research were 
scheduled for a time when it would 
have been difficult for me to do much 
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else in the way of high-level coding. 
Much of the game design was still in 
flux when Mike and Nate were develop- 
ing the DirectDraw libraries, resource 
builder, and basic program framework. 
None of this concerned us, however, 
as we knew what was required of those 
components regardless of game design. 
This freed me to continue tweaking the 
design and continue research even 
while other team members were busy 
coding. Note that when I was finally 
ready to begin coding the deer AI, the 
elements for allowing me to visualize 
the deer on screen were nearly in place. 


Lesson 4: Code 
Around Scheduling Delays 


n some instances, scheduling cannot 

be fudged enough to minimize 
dependencies and still give enough time 
for everyone to complete their tasks. Or, 
there may not be enough alternate work 
with which to fill up that person’s 
schedule. In this case, the best thing to 
do is simply to code around the prob- 
lem. This was somewhat of a problem in 
DEER HUNTER’s development. 

I was responsible for the deer’s Al 
and behavior. A problem arose when 
the map view took slightly longer than 
anticipated to get functional (with as 
tight a schedule as we had, even a week 
could make a huge difference). 
Without a graphical view into the 
deer’s world, it was difficult for me to 
maintain my schedule. 

In future projects, I would learn from 
this mistake and create a separate appli- 
cation exclusively for creating and test- 
ing animal movement and reactions. 
The next generation of hunting games 
were expected to have more advanced 
behavior, so I needed far more time to 
program the AI in our later projects. I 
used a third-party graphics library, Fast- 
graph for Windows, to create this test 
bed, because it had native support for a 
flexible floating-point coordinate sys- 
tem. The animals all used floating-point 
vectors for movement in a realistically 
scaled world, so this worked well for me. 

Your particular choice of libraries and 
tools doesn’t really matter, as long as 
you maintain a clear separation 
between the test bed and the game code 
that you're writing. This distinction 
also has another positive side effect: it 
forces programmers to maintain a clean 
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and intuitive programming interface to 
the code modules that they’re writing, 
because the code must be moved from 
the test bed to the main project. At 
some point, the actual project may 
become incompatible with the test bed 
due to increasing complexities in the 
game itself. Don’t try to maintain the 
two separate projects unless you’re 
absolutely forced to do so. Simply move 
the code to the main project and con- 
tinue working there. Keep in mind that 
the test bed is simply a means to an 
end, and once its usefulness has ceased, 
it should be discarded. Don’t make it 
too pretty by wasting time on irrelevant 
features. Quick and dirty is the key. 


Lesson 5: Create 
Meaningful Milestones 


t t’s too easy for those who can’t see 
under the hood of a project to want 
visual milestones. Oftentimes, howev- 
er, when a game looks only half done, 
the work is actually 90 percent com- 
plete, or vice versa. It’s important for 
project managers to understand this. 


SD ’°93 COM 


The easiest solution is to involve the 
designers, artists, and programmers in 
the task of creating milestones. Because 
they're the ones doing the work, they 
should have a more instinctive feel for 
how to balance out the workload 
among equally separated project mile- 
stones. This also helps to clarify every 
individual’s responsibilities right from 
the beginning. 

I've seen examples of both approach- 
es. When management alone tries to 
dictate the milestones, the results are 
often a huge, unbalanced mix of goals, 
which fall mostly into the “too easy” 
or “nearly impossible to achieve” cate- 
gories. When someone who appreciates 
the technical aspects of the design is 
involved, the balance between mile- 
stones tends to be much more realistic. 

You'll notice that all of these sugges- 
tions relate to design or other similar 
aspects of the project. Truth be known, 
that was really the only remarkable 
aspect of DEER HUNTER’s development 
cycle. The other parts were pretty 
plain: solid object-oriented design prin- 
ciples (or solid structured programming 
techniques for you C programmers), 
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careful programming, and hard work. 
The question of code reusability and 
robustness might come up, and it is 
indeed a valid point. Minimizing 
design time doesn’t necessarily mean 


sacrificing these elements. I would offer | 


proof of this by mentioning that the 
Same basic code set was used to create 
two derivative products, a big-game 
hunting simulation and a duck/goose 
hunting game. The success of DEER 
HUNTER was completely unexpected, 
yet we were able to use the existing 
code as an engine with which to create 
these other games, both of which made 
substantial improvements to the origi- 
nal game. DEER HUNTER has now even 
been ported to the Macintosh. There’s 
no question that the code was well- 
designed and quite robust. Individual 
programmers sticking to time-honored 
object-oriented programming tech- 
niques achieved the robustness of the 
code, not a fancy design document. 
Remember that design time is essen- 
tially overhead. The faster you can get 
your team up and working, the more 
time they’ll have to do what’s really 
important: produce the game. 


Enlist in a five day, hands-on 
SD ‘98 Bootcamp and learn how 
to build powerful and flexible 
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dates a lot of people. University courses 
in DSP come with thick textbooks, and 
many programmers have heard of this 
thing called the “Fourier Transform” 
that consumes terrifying amounts of 
CPU time. Recently, I was shocked to 
learn just how simple the concepts 
underlying DSP are, and how sophisti- 
cated effects are easily done using small 
amounts of CPU time. 


Motivation 


goal of most (if not all) game 

developers is to use interactive, 
realistic sounds in their titles. Many 
game programmers are familiar with 
the concept of “spatialization,” which 
is the practice of manipulating sounds 
to fool listeners into thinking those 
sounds are coming from somewhere 
other than the speakers. Vendors of 
spatialization products would like you 





ntroduction 
ound Filtering 


by Jonathan Blow 





e’re going to talk about the basics of 
sound filtering — playing with the var- 


ious frequencies that compose a sound 


effect — in real time. In the process, we'll 


take a small step into the world of digital sig- 


nal processing (DSP). 


to believe that these products will 
make your game stunningly realistic; 
the fact is that, though currently avail- 
able spatialization is a welcome feature, 
it’s only one of many steps that you 
must take to achieve realistic sound. 
Sound reverberates in closed spaces. 
In wide-open spaces, sound loses ener- 
gy as it travels; high frequencies fall 
away faster than low frequencies, 
changing the character of the sound. 
In fact, this change is affected by the 
weather conditions between the source 
and the listener. When a sound 
bounces off a sheer rock face, different 
frequencies are deflected in different 
ways. When you're strutting down a 
bilinearly-filtered hallway cradling 
your BFG-31337, and you see a nice 
scripted sequence of a monster disem- 
boweling a scientist on the other side 
of a thick polymer window, the crack- 
ing-bone effects should sound as 
though they’re vibrating their way 


And when we were all fallen to the earth, I heard a voice speaking unto me, and say- 


ing in the Hebrew tongue, jon@bolt-action.com, why persecutest thou me? It is hard 


for thee to kick against the pricks. 
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DSP is a topic that intimi- 


through a solid barrier — very different 
than the same event unfolding beside 
you in the open air. 

Some game-oriented 3D sound sys- 
tems, such as QSound or Aureal’s A3D, 
contain some features for distance 
attenuation, reverberation, and the 
like; but those features usually aren’t 
very sophisticated, nor do they give 
the developer enough control. Because 
I’ve never heard a sound API that let 
me say, “This cannon blast is happen- 
ing on the other side of an echoey 
ravine, and it’s passing through a 
damp fog bank on the way here, and 
the weather is very windy, and by the 
way I’m listening to the sound under- 
water,” I believe that more game devel- 
opers should learn to do this stuff 
themselves. (Some of the very latest 
games do use sophisticated filtering 
effects. UNREAL uses a filter to create a 
reverberation effect inside caves, and 
HALF-LIFE uses a filter to simulate sonic 
resonance when the player is crawling 
through air ducts.) 

In this article, we’ll cover the basic 
ideas behind achieving environmental 
effects through the manipulation of 
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frequencies within a sound. This tutori- 
al will be easier if we first accept a cou- 
ple of ideas about sine waves, without 
proof. These ideas aren’t too hard to 
swallow; ample references to explain 
them are given at the end of the article. 


Sine Wave Review 


af ecause we're going to talk about 
sine waves, let’s review some of 
their properties. Sine waves are little 
curved beasties made by the equation 
f(t) = sin(t). The argument f is given in 
radians; sine waves repeat themselves 
every 27m radians. We say that this 27 
radians is the wave’s period of repeti- 
tion, and we may think of period in 
the temporal sense: it is the amount of 
time the wave takes to repeat itself. The 
sine function can produce values from 
—1 to 1, so we say that the wave has an 
amplitude of 1 (Figure 1A). 

To amplify a wave, we multiply it by 
a constant A, so the equation becomes 
f(t) =A sin(t). If A is 2, then every point 
on the wave becomes twice as far away 
from the 0 line, and now the wave 
ranges from —2 to 2 (Figure 1B). To shift 
a sine wave to the side by an amount x, 
we add x to the time parameter: f(t) = A 
sin(t + x). We can change the frequency 
of the sine wave by accelerating the 
flow of time as the sine function sees it; 
to do this we multiply t by a constant: 
f(t) = A sin(kt + x) (Figure 1C). When we 
add sine waves together, the positive 
and negative values can cancel each 
other out, just like any other function 
(Figure 1D). 

The first remarkable fact that we’ll 
accept on faith is this: whenever we 
add two sine waves of the same fre- 
quency, the result is a sine wave of that 
frequency. This is easy to see if the 
waves are not shifted: A sin(kt) + B 
sin(kt) = (A + B) sin(kt), a wave with 
amplitude (A + B). However, the sum is 
still a sine wave even when the source 
waves are shifted: A sin(kt + a) + B sin 
(kt + B) = C sin(kt + y) for some C and y. 

Sine waves of differing frequencies, 
however, do not sum to produce a sim- 
ple sine wave. A sin(k,t) + B sin(k,t) = 
Something More_Complex(t) in gener- 
al. But this is a good thing, because 
sine waves themselves don’t make for 
very interesting sounds. It is by throw- 
ing them together and making a mess 
that we develop true character. 
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FIGURE 1. A. Sine wave y=sin(t). B. A sine wave with amplitude 2: y=2sin(t). C. A 
sine wave with a period of half of wave A.: y=sin(2t). D. When the two purple 
waves combine, destructive interference produces the green wave. 


Sound Wave Review 


hese days, we usually represent 

sounds as arrays of signed 16-bit 
integers. Each number in the array rep- 
resents a sample of a sound wave at an 
instant in time (Figure 2). The sound 
card converts our samples back into a 
continuous waveform so that they can 
be played. We will call this waveform 
— which is essentially just a function 
that varies over time — a signal. 

The second remarkable fact we’ll 
take on faith is that every signal (over a 
finite interval) can be represented as a 
sum of sine waves of differing frequen- 
cies. This brilliant realization is called 
the Fourier Theorem, named after Jean 
Baptiste Joseph Fourier, who came up 
with the idea early in the nineteenth 
century. (There is nothing too magical 
about sine waves that gives them this 
capability; the study of wavelets is all 
about how to decompose signals into 
varying wave shapes.) 


What This Means 


te Ow we are armed with two impor- 
tant facts: all sounds are composi- 
tions of sine waves, and two sine waves 
of the same frequency, added together, 
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produce a new wave of the same fre- 
quency. These facts give us the ability 
to look at sound in an enlightening 
new way. 

Suppose we want to mix two sounds 
together by adding them; the sounds 
are represented by functions f(t) and 
g(t), and we want to add them to pro- 
duce a new sound /(f): h(t) = f(t) + g(t). 
The old way of thinking about this is 
that, for each t, we evaluate f(t) and 
g(t), add those together, and the result 
is the value of h at t. According to the 
DSP way of thinking, we take all the 
sine waves that make up f, and all 
those that make up g, then we add 
them all together to get h. 

What happens if we add a sound f(t) 
to itself? f(t) consists of a bunch of sine 
waves, A, sin(k,f + a,). Working in the 
DSP way, we add all these sine waves to 
duplicates of themselves, then put 
them back together to get the result. 
f(t) + f(t) equals, for each n, A, sin(k, t + 
a) +A, SIN(K f+ 0,) = ZA, Sink 48, 
Every sine wave has twice the ampli- 
tude as before. When we put the waves 
together, it should come as no surprise 
that the result has twice the magnitude 
of the original f(t) at every point. f(t) + 
f(t) = 2f(t), after all. We’ve made the 
sound louder. The DSP way of thinking 
about sounds hasn’t bought us any- 
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FIGURE 3. A. A sine wave, added toa shifted version of itself, where the shift is 
small relative to the period of the wave. The wave mostly reinforces itself. B. A 
sine wave with a shorter period, shifted by the same amount. It ends up destruc- 
tively interfering with itself, producing zero. 





FIGURE 4. A graph of the frequency response of the low-pass filter in Listing 1. 
Frequencies are along the x axis; the y axis shows the scale by which each fre- 


quency’s amplitude will be multiplied. 


amplitude 


thing extra yet — but that was just a 
way of getting used to this way of 
thinking and convincing ourselves that 
it produces consistent results. 

Now, here’s a revealing thought 
experiment: what happens when we 
add the sound f to itself, but before 
adding, we shift one version of f by a 
small amount d? That is, if h(t) = f(t) + 
f(t + d), what does h(t) look like? 

Let’s look at the individual sine 
waves in Figure 3. If dis very small 
compared to the period of a sine wave 
A sin(kt), then the wave isn’t displaced 
much with respect to itself. So when 
we add A sin(kt) + A sin(kt + d), the 
result is very close to 2 A sin(kf), as in 
our last example (Figure 3A). 

But what happens when d is longer 
than the small displacement we just 
discussed; say, half a period long? We 
see the result in Figure 3B: A sin(kf) and 
A sin(kt + d) cancel each other out, pro- 
ducing zero. 
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frequency 





These cases represent two extremes. 


The lower the frequency of the wave 
(the longer its period), the better it 
will survive the summation process, 
approaching the ideal of doubling its 
original value. The higher the fre- 
quency (the shorter the period, down 
to 2d), the better it will be eliminated 
by the offset. 


It turns out that if dis the width of 
one sample, the highest frequency con- 
tained in the input sound has period 
2d (so says the Nyquist Theorem, 
which tells us how much signal infor- 
mation can be stored in a series of sam- 
ples); this is precisely the frequency 
that is completely eliminated by the fil- 
tering operation. A graph of frequency 
attenuation is given in Figure 4. 

If we take an array of integer sound 
samples, shift it by one sample, and 
add it to itself, we are performing a 
low-pass filter of the sound. If we’re 
representing a sound with 16-bit inte- 
gers, we want to add the samples 
using a larger number representation 
(say, 32-bit integers), then divide 
them by 2 to ensure that they don’t 
overflow when we pack them back 
into 16 bits (an issue familiar to any- 
one who’s ever mixed sound). Listing 
1 shows code for the low-pass filter 
that we’ve just described. 

With a simple reversal, we can use 
this same method to preserve high fre- 
quencies and eliminate low frequen- 
cies, a process called high-pass filter- 
ing. Rather than adding f(f) to itself, 
what if we subtract it from itself? That 
is, h(t) = f(t) -— f(t + d). This equation is 
the same as h(t) = f(t) + (-f(t + d)); we 
are negating one of the functions 
before we add. This has the effect of 
flipping one of the sine waves about 
the axis f(t) = 0. Now, the low frequen- 
cies, because they are hardly shifted at 
all, negate to cancel themselves out; 
the high frequencies negate to rein- 
force themselves (Figure 5S). 

You can imagine that, by specifying 
a d that is wider than one sample, one 
could mute frequencies in the mid- 
range. For example, if dis three sam- 
ples wide, we cancel all waves with 
periods of six samples. But a d of this 


LISTING 1. A subroutine that applies a simple low-pass filter to some samples. 


void lowpass_filter(short *samples, int nsamples) { 


static long last_sample = 0; 


ant i: 


for (i = 0; i < nsamples; i++) { 
long current_sample = samples[i]; 
long result = (current_sample + last_sample) / 2; 
last_sample = current_sample; 
samples[i] = result; 
} 
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value will also filter waves with a peri- 
od of two samples (because those 
waves are shifted by 1.5 times their 
period, which is the same as shifting 
them by .S times their period). This 
behavior would seem to place some 
heavy restrictions on the frequencies 
we'd be able to filter. It turns out, 
though, that by doing some geometry 
in the complex plane, we can obtain 
good control of our frequency response 
curve, including frequencies that can- 
not be represented by integer multiples 
of d. See the References section for 
more information about this. This type 
of filter is called a feedforward filter 
because, in producing output, it only 
uses past values of its input. 


Resonance and Feedback 


A nyone who’s been to an early-90s 
grunge concert knows what feed- 
back is. This goateed guy holds his gui- 
tar too close to the loudspeakers. The 
guitar pickups (essentially little micro- 
phones) catch the loud noise coming 
out of the speaker and transmit that 
noise back to the speaker, which tries 
to make it even louder. Soon, the audio 
system overloads and we’re left with an 
angry screech. 

We can apply this same idea to our 
audio filter, but in a more restrained 
and generally soothing way. What hap- 
pens if we generate our sound h(t) by 
combining f(t) with previous values of 
the output, h(t)? For example, h(t) = f(t) 
+ h(t-d)? For simplicity’s sake, we’ll 
measure fin samples, and d will be 1 
sample: h(t) = f(t) + h(t- 1). 

We can evaluate the first few terms 
directly: h(O) = f(O) + h(-1). We'll 
assume that all negative values of h are 
zero, so h(Q) = f(O). That’s simple 
enough. Also, h(1) = f(1) + h(O) = f(1) + 
f(0). So at the second sample, we’re 
adding f to an offset version of itself, 
just as before. Now, h(2) = f(2) + h(1) = 
f(2) + f(1) + f(O). As we repeat this 
process, we see that the pattern con- 
tinues forever. We’re adding together 
versions of f that are shifted by succes- 
sive amounts. 

What does this process do? Figure 6 
shows the result for waves whose peri- 
ods are much longer than two sam- 
ples. As we saw before, adding the 
wave to a shifted version of itself will 
cause the wave nearly to double in 
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FIGURE 5. A. We perform the kinds of summations that took place in Figure 4, 
but first we negate the orange waves. The dashed light blue curves represent the 


position of the waves before negation. 


Now, the low frequencies, as in A, are 


killed; the high frequencies, as in B, are doubled. 


amplitude. But now, to output the 
next sample, our feedback loop shifts 
that result wave again and adds it back 
to the original. Now, the result is even 
greater in amplitude — though 
because it’s shifted further, it doesn’t 
reinforce itself quite so strongly. After 
enough repetitions, the wave will 
become out of phase with the original 
version of itself, and the feedback will 





serve to reduce its amplitude rather 
than increase it. 

We have to be careful with this kind 
of situation. Figure 6B shows what hap- 
pens when we feed back a wave with a 
delay time that is a multiple of its peri- 
od. The amplitude of the wave climbs 
toward infinity, which leads to total 
chaos. For this reason, we must multi- 
ply feedback signals by a constant of 


FIGURE 6. A. The effect of feedback on a wave where d is misaligned with the 
wave’s period. As we add it to shifted versions of itself, the result will wax and 
wane in amplitude, never growing beyond a certain point. B. If d is aligned with 
the wave’s period, the wave will continue to grow with each round of feedback. 
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magnitude less than 1, to damp them. 
Thus, h(t) = f(0 +k h(t-1),-1<k<1. 
Then the feedback filter is stable. 

Listing 2 shows code for a simple 
feedback filter. The frequency response 
of this filter is shown in Figure 7. Note 
the relative sharpness of the peak — 
feedback filters allow us to alter frequen- 
cy response more dramatically than the 
feedforward filters we talked about earli- 
er. Note also that it amplifies some fre- 
quencies by large amounts. To keep our 
number representation from overflow- 
ing, we compute the maximum amplifi- 
cation when we build the filter; later, as 
we Output samples from the filter, we 
divide them by that factor to normalize 
the sound, thus preventing overflow. 

As Figure 7 shows, feedback allows us 
to pick out certain frequencies and 
amplify them much more than others. 
It is said that the filter resonates at 
those frequencies. Interestingly, this is 
. the same effect that occurs with sounds 
made in enclosed spaces. They resonate 
according to the shape and dimensions 
of the cavity, whether it’s a yawning 
cave or a Stradivarius violin. Many 
physics books describe the reflection of 
waves between two surfaces, and in 
such descriptions, one can easily see 
the mathematical equivalence. 


Implementation 


3 n our feedback filter, we ended up 
multiplying samples by floating- 
point values to damp them. For most 
feedforward filters, we want to use 
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floating-point math as well. 
Generally, we’ll convert our 16-bit 
source samples to floating point and 
operate on the floating-point samples. 
For cases in which we’re algorithmi- 
cally generating a sound, instead of 
reading that sound from a file, our 
original samples will probably be in 
floating point. 

Interestingly enough, new instruc- 
tion sets such as AMD’s 3DNow and 
Intel’s new Katmai instructions con- 
tain stuff that’s great for processing 
sound in floating point. Unfor- 
tunately, almost every sound API (3D 
or not) wants samples fed to it as inte- 
gers. Therefore, we must convert our 
floats back to integers, consuming a 
little extra CPU time and reducing 
accuracy. These extra calculations are 
especially irritating because the sound 
library usually will convert the sam- 
ples right back to floating point (for 
example, to scale the volume of the 
sounds so that they can be mixed into 
a single channel). Let me offer this 
plea to the makers of sound APIs: give 
us an interface that takes samples in 
floating point! 

The example code that accompanies 
this article will demonstrate the effects 
discussed here, along with some oth- 
ers, such as pitch shifting and rever- 
beration. (Reverberation works just 
like the filtering examples we’ve dis- 
cussed already; the main difference is 
that the filter delay d is much longer, 
to the point where the delay is audi- 


ble.) The code is available on the Game 


Developer web site. 
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Now You Try It 


WW e’ve seen some low-level ways 
to manipulate the frequency 
content of sound. We haven't said 
much about how to put sounds togeth- 
er, though. If an explosion happens 
inside a sealed vault, you probably 
want to low-pass filter that sound for 
listeners on the outside; but exactly 
what frequency response to use, and 
how to make a filter to give you that 
response, could be the subject of an 
entire book. 

We've tried to present sound filtering 
in an introductory way that is different 
from the approach taken by most text- 
books. That way, upon further reading, 
you'll be exposed to ideas from a differ- 
ent direction, which can provide fresh 
insight. We certainly have not been 
rigorous here. In fact, we’ve tried to use 
as few mathematical ideas as possible; 
some of the References present filters 
in an elegant way that requires more 
background. In any case, further read- 
ing is required to accomplish a sophis- 
ticated understanding of filters. 


REFERENCES — : | 
© Everybody in the world shoul read A a 
Digital Signal Processing Primer, v W 
Applications to Digital Audio and ~ 
| Computer Music (Addison-Wesley, 
by Ken Steiglitz. Starting w with so 
ple mathematical expositior } . tc 
straight through DSP theory in 
accessible way lve seen to date. 
_e After that, read section 14.10 of : 
Clare copies ners and 
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back to the Game Developers Conference year after year. They know that in a fast- 
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Authoring System 
for 3-D Realtime Computer Games 


Create cool 3-D adventures without programming! 
@ Contains World Editor and the ACKNEX 3-D engine 
@ Free 3-D template game with 150+ textures included 


@ 3-D polygonal landscapes with slopes, bridges, buildings 
@ Player can walk, drive, fly, climb, swim, dive... 

@ Self-defined panels, overlays, cockpits, and scrolling text 
@ Create your own objects, actors, walls, weapons, menues 
@ 320x400 256 color smooth scrolling VGA resolution 
@ 8-channel stereo sound & midi support 

@ Imports PCX, LBM, MDL, WAV, MID and IBK files 

@ 200+ pages English manual with game tutorial 


> 16h Ne 


(+ Folaeial i a 4 ‘CD-Audio 4 fue player) 


Prices +$20 for overseas shipping / $40 for additional email delivery 
Infos, demos, ordering — => > hetp://www.conitec.com 


Germany # D-64807 Dieburg = Dieselstr. Tic 
Tel +49 6071 92520 Fax 925233 s www.conitec.com 





Product Company URL Phone Page 
3D Studio MAX KINETIX HTTP://WWW.KTX.COM/ (415) 547-2000 16, 23, 58 
A3D AUREAL SEMICONDUCTOR HTTP://WWW.AUREAL.COM (510) 252-4245 50 
CAKEWALK CAKEWALK Music SOFTWARE HTTP://WWW.CAKEWALK.COM (617) 441-7870 58 
DIRECTOR MACROMEDIA HTTP://WWW.MACROMEDIA.COM (415) 252-2000 62 
GAME EXCHANGE NICHIMEN GRAPHICS INC. http://www.nichimen.com (310) 577-0500 16 
LiGHTWAVE NEWTEK http://www.newtek.com (210) 370-8000 16 
MAYA ALIASIWAVEFRONT HTTP://WWW.ALIAS.COM (800) 447-2542 16 
NOMAD /VirTUAL HUMAN SDK 1.2 LEARNING MACHINES HTTP://WWW.LMTG.COM (408) 505-5398 9 
PHOTOSHOP ADOBE HTTP://WWW.ADOBE.COM (408) 536-6000 23,58 
POWERANIMATOR ALIASIWAVEFRONT HTTP:/ /WWW.ALIAS.COM (800) 447-2542 16, 23 
PoweER Goo METACREATIONS HTTP: //WWW.METACREATIONS.COM (805) 566-6200 63 
QCREATOR QSOUND LABS HTTP://WWW.QSOUND.COM (403) 291-2492 9 
QSouND QsouND LaBs HTTP://WWW.QSOUND.COM (403) 291-2492 50 
RENDERMAN TOOLKIT PIXAR ANIMATION STUDIOS HTTP://WWW.PIXAR.COM (510) 236-4000 24 
SOFTIMAGE SOFTIMAGE http://www.softimage.com (514) 945-1636 16 
SOUND FORGE SONIC FOUNDRY HTTP://WWW.SONIC FOUNDRY.COM (800) 57 SONIC 58 
TRUESPACE CALIGARI CorP. HTTP://WWW.CALIGARI.COM (650) 390-9600 58 
TRUETIME COMPUWARE (NUMEGA) HTTP://WWW.NUMEGA.COM (603) 578-8400 12 
ViSKIT PARADIGM ENTERTAINMENT INC. HTTP://WWW.VISKIT.COM (972) 960-2301 9 
VISUAL C++ MICROSOFT HTTP://WWW.MICROSOFT.COM (425) 882-8080 58 
VTUNE INTEL HTTP:/ / DEVELOPER.INTEL.COM/DESIGN/PERFTOOL/VTCD (800) 253-3696 12 
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POSTMORTEM 


Goldtree’s 
EAD RECKONING 





by Luke Ahearn 






EAD RECKONING is Goldtree’s latest title and is a new 





chapter in first-person vehicle-based games. As a 


player in the, game you’ve been abducted by 
the Master Race to engage in gladiatorial com- 
bat against the best warriors of every know alien 
race in the universe. If you loose, Earth and all of 
mankind is destroyed. Before you begin, you choose your wingmen 
from among many characters — each with 
his or her own personality; personality 

@ traits include loyalty, obedience, aggres- 
siveness, and more. And you choose your 


ship. Each has varying rates of firepower, 


oO al 
Px<<> 





shield strength, and speed. Most important 














Luke Ahearn has been Lead Designer and Producer at Goldtree for five titles, including DEAD RECKONING. 
He is currently developing Goldtree’s next title. Before games, Luke wrote novels, worked in the film indus- 
try, and did every dreadfully boring, menial job you can think of while going through college. He can be 

reached at luke@goldtree.com. 
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are the special weapons; chameleon powers, mines, traitor 
bombs, holographic decoys, and the Death Blossom are a few. 

Combat takes place in huge cylindrical arenas, each varied 
in environment. There are arctic wastelands, the tombs of 
Egyptian kings, and asteroid belts. You can fight in a lake of 
lava or the innards of a giant creature. Goldtree wanted to take 
players off of the floor in QUAKE and out of the confining tun- 
nels of DESCENT. You are in arenas where you have room to 
maneuver, but the firefights are quick and intense. The game 
demands more than simple twitch reflexes. You must select 
the right ships for you and your wingmen, give your wingmen 
orders, and monitor your resources. You must tag pylons to 
increase your weapon’s strength, hover over the energy field to 
recharge your shields, and above all, kill your enemy. 

As the game’s designer and producer, I will focus this 
Postmortem on DEAD RECKONING’s design. In some ways, 
DEAD RECKONING is a remake of our previous title 
CYLINDRIX; in other ways, the two games are worlds apart. 
CYLINDRIX was greatly admired by many game players and 
received great exposure online for its game play. But it 
lacked certain mass-market features such as textures and 
solid net play, and we were plagued by many problems 
while trying to publish CYLINDRIX. 

After we finished CYLINDRIX, Goldtree was ready to pro- 
duce the A+ title that we knew we were capable of produc- 
ing. We were discussing what that title would be when 
Piranha Interactive expressed interest in a sequel to 
CYLINDRIX. Eventually, Goldtree and Piranha decided that we 
shouldn't make a sequel to a game that the world-at-large 
hadn’t heard of, so we made DEAD RECKONING a game of its 
own. We felt this decision was legitimate, as the differences 
between the two games are vast in most areas. 

The completion date for DEAD RECKONING was pushed off 
for almost a year, but the big delay was primarily due to the 
fact that Piranha believed that DEAD RECKONING would be an 
A+ title and didn’t want to squander its resources on a half- 
baked launch. The company saw opportunities to improve 
vastly the game’s value in the marketplace. Piranha seemed 
immune to the popular attitude that a publisher can dump 
anything into a box and then rely on sales and marketing to 
make the game successful. Developers see things from the 
opposite point of view. A great game will sell by word of 
mouth as the demo works its way rapidly across the Internet. 

Piranha’s long-term thinking and support allowed 
Goldtree to redevelop some critical areas of DEAD 
RECKONING, including support for online gaming services, 
Microsoft’s force-feedback joystick, and the ability to sup- 
port user-created levels. Supporting custom levels included a 
great deal of reworking of the game code and the level editor 
that we used during development. For the level editor, we 
hired Rosetta Game Development. 

The level editor was never intended to be used by the end 
user, and as a result was undocumented and pretty hard to 
use. While I was writing the user manual for the level editor, 
Rosetta started improving the editor itself. With very little 
time to work on the editor, they couldn’t make it perfect, 
but were able to fix some bugs, make usability improve- 
ments, and add significant functionality. 

The level editor has an object-oriented design based on 
“entity” classes for each kind of game object, and it shares 
these classes with the game itself. The editor is a placement 
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: : ‘Boldt pe Development Team 

DEAD RECKONING’s development team — Goldtree: (from left 
to right, top row) Luke Ahearn, Designer/Producer; Anthony 
Thibault, Lead Programmer; Nicholas Marks, Art Director; 
(bottom row) John McCawley, Al Programmer; Michael 
Freimanis, Menu Programmer; Josh Eustis, Musical Director 
and Engineer; (not shown) Ted Baldwin, cut scene anima- 
tion; TJ Bordelon, consulting programmer; Dan Farrell, 
Menu Prototype. RA Studios: (from left to right, back row) 
Richard Laquale, Brian Kennedy, Daniel Venditelli, (front 
row) Stephen Capasso, Matthew Zanni. Rosetta: (not 
shown) Scott K. Warren. 


tool only, so new object shapes must be created in an appli- 
cation such as 3D Studio MAX and then imported into the 

level. The editor allows users to manipulate all of the game- 
play properties of an entity, such as the recharge rates of an 
energy field, the explosion file that’s played when a certain 
entity is destroyed, and the start points for players. 

The usability improvements to the editor included single- 
level undo; keyboard shortcuts for commonly used opera- 
tions; arrow-key nudges for fine motion; browse buttons 
everywhere a filename must be specified; and consistent dia- 
log naming, layout, and keyboard operation. 


DEAD RECKONING 


Goldtree Game Developers 
Metairie, La. 

(504) 837-0080 
http://www.goldtree.com 

Team Size: Eight in-house. RA Studios completed the game and 
demo, adding support for many features and fixing bugs. 
Rosetta updated the level editor for users in the contest. 

Release Date: September 1998 

Title Budget: $350,000 (ballpark) 

Time in development: 24 months 

Intended game platform: Windows 95/98 with DirectX 5 (will 
run solid under DirectX 6). We are in the process of recompil- 
ing for DirectX 6 and expect a significant improvement in per- 
formance. 

Critical hardware: A network of eight Pentium 200s that 
allowed the rapid compiling and testing of the game. Audio 
setup with several large drives, CardD and digital daughter 
card, DAT recorder, ROM burner, and a ton of really cool musi- 
cal stuff the musician brought in. 

Critical software: Direct X 5.2a, Photoshop 4, trueSpace 2, 3D 
Studio MAX, Sound Forge, Cakewalk, Visual C++. 
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In its review of DEAD RECKONING, the Adrenalin Vault compared the game’s cast of characters to the bar scene in Star Wars. 





Some of the primary new features 
that Rosetta implemented were the 
Turret Property Sheet, the Find Object 
dialog, the Level Summary dialog, and 
the ability to automatically import 
assets. Turrets are the most complicated 
entity in the game, yet our original edi- 
tor provided no support for altering 
their properties, which were specified by 
an external text file. We had Rosetta add 
a fancy tabbed dialog so all properties 
could be seen, edited, and checked for 
validity within the editor. The Find 
Object dialog displays a scrolling list of 
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The original storyboard and the ren- 
dered version of the final victory cut 
scene. 
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all the entities in the level. Users can fil- 
ter the list by entity type and can select 
any listed entity for editing. The most 
interesting feature of this dialog is the 
Look At Object button, which reposi- 
tions the camera to bring the selected 
entity into view. Heuristics are used to 
pick a suitable camera pose and distance 
from the object, with the camera com- 
ing in closer for smaller objects. 
Unfortunately, we didn’t have time for 
Rosetta to make these heuristics fool- 
proof, so it’s possible that the looked-at 
object will be obscured by something in 
the camera’s way. In practice, I’ve found 
this to be rare. The Level Summary dia- 
log not only lists statistics about the 
objects in the level, but also offers a 
Verify button, which checks whether 
every asset mentioned by the level has 
actually been imported into the level. 

While Piranha was investing the 
additional time and resources in the 
marketing of DEAD RECKONING, bring- 
ing on Epicentric to help, they also 
cosponsored a level-design contest. 
This contest was the reason we rebuilt 
the level editor. Piranha also retained 
some serious marketing talent internal- 
ly to help push DEAD RECKONING. 

And, of course, Goldtree took this 
opportunity to optimize the code and 
fix many bugs. For this effort, we 
brought in RA Studios. By the time RA 
Studios received the code for DEAD 
RECKONING, the game was almost com- 
plete. Once again, time was short; the 
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game needed to be ready to go gold 
within two months, so the program- 
mers at RA needed to get acquainted 
with the code very quickly. We tasked 
them, primarily, with getting a better 
frame rate out of the engine, which 
was running at about 9-15 FPS on a 
Pentium 200 MMx. Better, in this case, 
meant 200 percent better, so trying to 
find the culprit for this performance 
problem was paramount. Because the 
engine was already complete, as was 
most of the game around it, it proved 
difficult for them to fix the speed issue 
without breaking the game. However, 
in the end, with tweaks to the collision 
routines and some rendering routines, 
RA achieved a comfortable 30 FPS. 


L ooking back over the last two 
years, I can say that for all of the 
challenges that besieged us during the 
development of DEAD RECKONING, good 
up-front design is what guaranteed the 
delivery of a high-quality finished 
product. I believe that in a game com- 
pany, design issues are the most impor- 
tant aspects of a project, even above 
business issues. Although written 15 
years ago, The Art of Computer Game 
Design by Chris Crawford still holds 
some great advice and observation 
about game design. He says, “There is 
no easy way to produce good computer 
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A rogue’s gallery of characters from DEAD RECKONING. 





games. YOu must start with a good 
game designer, an individual with 
artistic flair and a feel for people.” | 
believe the best approach to designing 
a game consists of working in the fol- 
lowing three areas. 

Obviously your primary area of 
absorption should be in gaming, espe- 
cially within your genre (first-person, 
strategy, and so on). This effort should 
include not only playing games, but 
reading all the magazines, surfing the 
Net and browsing through news 
groups. From a design standpoint, I 
find that it’s easy to lose touch with 
what a good game is by simply taking 
your eye off of the moving target (the 
game market as a whole) for even a 
brief period of time. 

[ also find it very helpful to read 
books, watch movies, and pursue other 
creative fields. There’s much to learn 
from how a movie is scripted and story- 
boarded that applies to game develop- 
ment. Understanding how a novel or 
short story is written and constructed 
(and what actually makes a good story) 


A concept sketch of our original menu 
idea. After mocking it up we deter- 
mined that it was too unwieldy and 
inflexible. The time was not wasted. 
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helps a great deal when detailing your 
game on paper. I find that most of what 
I do is reading and writing. Writing 
skills are used in business reports, game 
treatments, product submissions, 
anonymous flames... the list is endless. 

Finally, I turn to traditional project 
management a great deal for the tools 
that are critical in developing any seri- 
ous undertaking. You simply must 
take the time to develop the work 
breakdown structure, master schedule, 
project budget, and other necessary 
documents in order to maintain con- 
trol of your development. As W. 
Edwards Deming points out, “Fire pre- 
vention is far better than fire fight- 
ing.” And there is no better way to 
instill the publisher with the confi- 
dence that you understand the job 
that must be done and can do it. 

The initial stages of open discussions 
on DEAD RECKONING went well. We had 
time to think long and hard about 
what we liked and didn’t like about 
CYLINDRIX and what we would do dif- 
ferently in the design and development 
of our next title. Like most developers, 
we wanted to improve on the concept 
and technology we understood best, 
and not start from ground zero again. 
We decided to stick with the approach 
that we developed for CYLINDRIX: a 
hardcore game that required that play- 
ers be seriously good at gaming, well 


We built the menu as a 3D model in 
3D Studio MAX. 
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rounded, and not just fast. We felt that 
enough people had become so well 
acclimated to 3D games such as QUAKE 
or DESCENT, that they were ready for 
something harder. No cheat codes or 
camping, but not just toe-to-toe com- 
bat either. Slower players on the con- 
trols should still be able to defeat frag- 
masters by being more strategic and 
managing their wingmen, weapons, 
and overall battle plans better. 

Originally, we had no intention of 
allowing difficulty levels to exist other 
than nightmare, and we even made the 
enemy AI better than your computer 
teammates later in the game. After 
some initial play-testing by the pub- 
lisher and reviewers, we realized that 
this intense gauntlet actually made 
some people really tense; we made 
some concessions (although they were 
few). We allowed an automatic save 
game option that starts you at the 
beginning of the level where you died. 
We also toned down the A/a little. 
Games are supposed to be fun. 

On the other hand, as game enthusi- 
asts, Our proficiency in games was 
deceiving to us and caused a bit of 
design drift. After countless hours of 
QUAKE, DUKE NUKEM, DESCENT, 
WARCRaFT, and all the other really 
great games out there, we got really 
good. We felt as though we had a han- 
dle on the design issues early on that 
could prevent last minute work, 


@ 

















The background for the main menu. 
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rework, and confusion. But we also got 
so good at gaming that we lost touch 
with our audience. So we had to tone 
the game down a bit. 

In addition to all the game play 
issues, we tackled several important 
technical decisions early on in the 
design process. We choose to support 
DirectX and Windows 95 because it 
looked as though the industry was 
moving that way, and we liked the idea 
of not having to write for specific hard- 
ware. One of our frustrations during 
the development of CYLINDRIX was that 
a great deal of our programming time 
was spent writing for hardware and not 
for the game. We took one look at 3D 
hardware performance and knew we 
had to support it. 

Another benefit to having your game 
designed early and in terms a publisher 
will understand is that it gives you a 
firm footing when approaching and 
dealing with a publisher. While we 
positioned DEAD RECKONING as a game 
enthusiasts’ game, we also had that 
“first-person, 3D, textured polygon, 
hardware-accelerated, multiplayer, 
super dooper thingy” buzzword stuff 
going for us. Initially, an unnamed 
individual at Piranha was pushing us to 
make the game “like DESCENT” (he 
doesn’t work there anymore), which 
would have doomed DEAD RECKONING 
to “me too” status. I was prepared with 
a well thought out game design that 
addressed our publisher’s desire for 
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uniqueness and familiarity. Piranha lis- 
tened, bought into it, and backed us all 
the way. 

The “different but same” problem (as 
first brought to the American con- 
sciousness by the Karate Kid) is similar 
to that which faces writers. Aristotle 
defined the major plot situations that 
exist in drama and as far as I know, no 
one has added to them. But think of all 
the unique and great literature (not to 
mention films, radio, computer games) 
that has sprung up since the classical 
Greek period. Our genres are defined 
for the near future, and it is our job to 
be creative, unique, resourceful. 

Design work is not all talking and 
sketching. We actually made proto- 
types and designed as much as possible 
using various software tools. Even with 
limited time and budgets, we used flow 
charts, storyboards, and fleshed out the 
look and feel of the menus and game 
flow as much as possible. We made a 
prototype of the entire menu system in 
Director and saved a great deal of work 
in the end, having been able to try out 
several versions of the menu first. We 
also became aware of how much illus- 
tration, fiction, and graphics had to 
done before we began working in other 
areas. DirectX allowed us to work in 
retained mode, which isn’t good 
enough for a real-time 3D game, but 
did enable rapid prototyping. 


What Went Right 


PLAYING GAMES AS MUCH AS POSSIBLE 

@ AND BEING SERIOUSLY TAPPED INTO THE 
GAME MARKET. Of course, this fact is obvi- 
ous to developers and need not be 
mentioned to a true game enthusiast. 
But for all you suits out there, you have 
to play games to make them. You have 
to go on the newsgroups, read the mag- 
azines, and surf the Net incessantly. 
I’ve actually heard that some compa- 
nies (game companies) have instituted 
a “no games” policy. What is the world 
coming to? 

Without a deep and intimate 
knowledge of games and the market- 
place, we cannot design good games. 
And, in actuality, we aren’t designing 
games for today, but for the market- 
place two years in the future. We all 
know how rapidly this market 
changes. In other areas, even in other 
areas of application development, one 
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doesn’t need to be as tapped into the 
market and core audience as we do. 
We have to anticipate the desires of a 
group of people (game players) that 
will invest heavily in upgrades and 
new technology when it arrives and 
change the game development land- 
scape dramatically in a short time. 

In defense of the suits, you do have 
to make games to sell them. During 
DEAD RECKONING’s development, we 
erred on the side of too much play 
while trying to keep stress levels down. 
I feel that the title still benefited more 
than if we had taken the opposite 
approach. We were aware of what play- 
ers wanted and could more easily guess 
at what they would want in the future. 

3D HARDWARE Support. If there was 

@ ever one thing I knew for sure, it 

was that 3D hardware would take off. I 
knew that just like the sound card, 3D 
acceleration would become a standard, 
something that you just had to have if 
a game was to even make it. 
Unfortunately, I didn’t buy stock — 
but I knew. We decided to support soft- 
ware rendering as well, because we 
thought the game would be out a little 
earlier and we wanted to reach the 
largest possible user base. Had we not 
supported 3D hardware, especially after 
the delay in completion, we would 
have been sunk or delayed even fur- 
ther. DEAD was designed to run well on 
any 3D card, and run extraordinarily 
well on a 3Dfx-based card. DEAD uses 
MM<X as well. 

CHOOSING THE RIGHT PEOPLE TO WORK 
c Finding the right publisher is 
something I spent a lot of time on as 
well. I ended up with Piranha 
Interactive and have not regretted it for 
one second. I specifically targeted a 
mid-sized publisher with the main pur- 
pose of protecting the game itself. | 
wasn't ready to tangle with the monster 
companies, although as a matter of 
education, | approached and spoke 
with many. I ended up with a handful 
of smaller but promising publishers. 
The benefits for a freshman developer 
are more attention and collaboration — 
your design ideas are treated more seri- 
ously. With a larger publisher, you run 
the risk of getting lost in the shuffle 
and being told, “Do it this way, or else.” 

In the process of educating myself 
as a developer over the past several 
years, I read a lot, spoke to everyone | 
could, and attended all the major con- 


http://www.gdmag.com 








ventions (E3, CGDC, Comdex, and so 
on). I heard all the horror stories 
about developer-publisher relation- 
ships and have a few of my own. I’ve 
come to see how many of these situa- 
tions crop up, and rarely is it blatant 
malevolence on either party’s part. 
Mostly, I fear it’s the vast difference 
between how a guy in a suit thinks 
and how the developer thinks. There 
is much room for misunderstanding. 
And when putting together the team 
for DEAD RECKONING, I looked for pas- 
sion and attitude. There is nothing 
more valuable. Attitude is what keeps a 
person working through such a long 
and trying project as a computer game 


when there seems to be no end in sight. 


Passion is what makes one’s work stand 
out. We had plenty of passion and atti- 
tude in all our team members. I’m still 
amazed that we did what we did with 
so few people and so few resources. 
DirEcTX. [his decision was made 
4, early on mostly because it 
seemed as though it would cut out a 
good portion of work for us, and it did. 
It allowed us to focus a great deal more 
of our energies on the game. The 
DirectX beta team was responsive and 
helpful. DirectPlay was particularly 
helpful, as was Direct3D Retained 
Mode for creating the level editor. We 
actually looked at other APIs, but not 
for long. We felt that DirectX would 
become the standard and be the best- 
supported API. I likened this decision 
to choosing the operating system for 
your game. You're going to want the 
largest market possible. 
WORKING WITHIN OUR LIMITS WHILE SET- 
@ TING HIGH GOALS. This is good design 
practice, especially for a small team. 
Working within one’s limits is a con- 
scious, not constrictive, process. 
Designing a really great game means 
leaving out features that you simply 
cannot accomplish. It prevents you 
from setting out on a journey you 
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could never complete. 

We started by listing what we all felt 
we could do well and what we felt we 
couldn’t do well. For example, we con- 
cluded that implementing really good 
character animation would be more 
work than we could handle, and I 
believe we were right. We focused on 
the physics and behavior of the ships. 
We wanted time to make each arena 
unique, even down to the sounds and 
projectiles of the turrets and obstacles 
in each game level. 

We also went from trying to create 
character art in 3D Studio MAX and by 
hand illustration to photographing 
models and photo-manipulating them 
with Power Goo, Photoshop, and a little 
3D augmentation. This turned out to be 
a better route all around. It was cheaper, 
quicker, and much nicer looking. 


What Went Wrong 


DESIGN DRIFT. Design drift can be 

e very subtle or blatant. It can be 
individuals tearing out on their own 
paths during development or an 
unconscious drift by the whole team, 
much like the example that I gave ear- 
lier: we became too good at our own 
game and made it a bit too hard. We 
had to redo many aspects of the levels, 
Al, and game play. 

Be mindful of design drift. Publishers 
are more likely to be too rigid when 
allotting more time or money for a 
neat feature, but developers tend to 
want to make the perfect game and go 
overboard. In the case of DEAD 
RECKONING the publisher wanted more 
time and money spent on the title and 
supported Goldtree’s decision to make 
a major shove at redeveloping portions 
of the game at the end — giving us 
more time, money, and support to 
make DEAD RECKONING a better game. 
But this was a conscious decision by 
both parties and not a drift. 

Drifting is when you’re unwittingly 
off course. One thing that’s useful is to 
keep the vision in the hands of the pro- 
ducer, project manger, or one person 
designated to filter all changes through 
the entire team. 

We faced many drifts that were usu- 
ally the result of talented and perfec- 
tionist individuals trying to make the 
game as good as possible. It’s a hard 
judgment call to make when dealing 
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The more human-like characters 
(“Panther” is on the right) were cre- 
ated from photographs. In addition to 
Photoshop work, you can see where 
the artist used Goo to reshape the 
head fora more feline appearance. 





with talent trying to perfect some 
aspect of their craft. Do you stop their 
creative process to make the milestone, 
knowing that you may impact the qual- 
ity of the game, lower morale, and/or 
cause the passionate individual uncon- 
sciously to adopt a new lower standard? 
Sometimes, decisions were made by 
individuals that affected the rest of the 
development and these decisions were 


The concept sketch and an in-game 
screen shot of the Energy Square in 
the Sentry arena. 
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The armor for the Biomechanoid character was built in 3D 
Studio MAX. The artist took a snapshot of the finished 


p] nd QB 
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model, which was then composited with the rest of the char- 


acter’s image using Photoshop. 





not communicated to the rest of the 
team. For instance, the decision to take 
the animated sequences down from 
640x480 to 320x200 upset the anima- 
tor. His work was deteriorated and he 
wasn’t told that he didn’t need to ren- 
der scenes out in 640x480. This wasted 
his time. 

We also faced some small drifts that 
were caused by the relative meanings 
of plain old words in the English lan- 
guage. A programmer may say “large 
file” meaning a 100K and the artist 
may think 1OOMB. 

Also, 3D game modelers are often 
different animals than the commercial 
3D modeler. A game modeler knows 
what low polygon count means and is 
adept at building objects face by face. A 
commercial or animation-grade model- 
er often builds everything using multi- 
ple primitives and very few texture 
maps. Usually, after explaining that the 
gorgeous 30,000-face demon has to be 
optimized to, say, three hundred faces 
in order to run in the game, the learn- 
ing curve that the latter modeler has to 
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overcome will take 
several extra weeks 
at a minimum. 

Any aspect that’s overlooked, 
whether out of ignorance or inexperi- 
ence, will cause a drift. This is the rea- 
son for proper planning and continued 
monitoring of the project. 

MORE INPUT EARLIER IN THE DEVELOP- 

@ MENT OF THE GAME. [’m not just talk- 
ing about compatibility testing and 
input from the publisher. I wish we 
had had more comprehensive testing 
and feedback from game players 
throughout the entire development of 
the game. | think many of the best 
ideas for a game, indeed what makes a 
game a success, are the users’ exten- 
sions of that game; MODs, add-on lev- 
els, and so on. We should have 
planned the level design contest earli- 
er, anticipated add-on levels earlier in 
the coding and started work on the 
level editor and its documentation 
much sooner. 

I believe this would have also helped 
us more accurately anticipate what the 
market would want and deliver it, or at 
least be prepared to explain why 
weren’t able to deliver it. 


Gaeeneeees 


1993 


The DEAD RECKONING level editor. 





A BETTER LEVEL EDITOR. We should 
3. have spent a lot more time 
designing and developing the level edi- 
tor up front. | think we all felt pres- 
sured and excited to dive into the game 
and simply forged ahead. I’m sure the 
editor was low on the programmers’ 
priority list at the beginning of devel- 
opment as they were faced with a 
mountain of problems to solve for the 
game itself: physics, Al, networking, 
learning new technologies, and playing 
DIABLO until sunrise. 

Since the level editor was never 
intended for use beyond the comple- 
tion of the game, this list of priorities 
wasn’t something that felt wrong at 
the time. But we should have anticipat- 
ed this discrepancy. A better level edi- 
tor would have made it easier on the 
artist and easier for others to work on 
level-design—related tasks. The level 
editor was difficult and ended up being 
reworked and overhauled for the level 
design contest. Had we made the level 
editor easier to use up front, I’m sure 
the game would have had more and 
better levels. 

IMPROPER CODE VERIFICATION, PROGRAM 
& @ DOCUMENTATION, AND ARCHIVED ASSETS. 
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Never put all your eggs in one basket, 
always verify code independently, keep 
redundant back-ups, and document 
everything. At least one other third- 
party programmer should be familiar 
with your code for numerous reasons, 
and all creative assets should be 
archived — and not just the final ver- 
sions of the files. A flattened Photo- 
shop image is impossible to manipu- 
late, undocumented code is hard to 
work with, and applications with no 
file sizes, standards, or parameters are 
almost useless. When any member of 
the team moves on or dies, their work 
will be hard to alter or modify if disor- 
ganized, undocumented, and improp- 
erly backed up. 

During DEAD RECKONING’s develop- 
ment, I laid out the schedule for back- 
ing up and archiving assets, but never 
enforced it. When the time came to 
retrieve and utilize these assets, they 
weren't easy for me to use. In the end, I 
had to spend more time digging 
through files with which I should have 
already been familiar. 

For me personally, the most frustrat- 
ing instance of this was having to go 
back and work with flattened, low-reso- 
lution images. I waited until too late to 
try to get these files, as | assumed they 
were being saved. During development, 
the artist created Photoshop files of the 
characters in the game; some of these 
images were as large as 25MB. As he 
needed more hard-drive space, he delet- 
ed these large images. It was months 
before the publisher began requesting 
these images for the ads, boxes, and 
other layouts. Needless to say, I felt 
foolish for not having them available. 

The level editor was also totally 
undocumented. When we decided to 
host the level design contest, we had to 
document the level editor — thorough- 
ly. With all that was happening in the 
last few months of development, this 
was a great burden. 

MISUSED “PROFESSIONALS.” 
5. Technically, this “wrong” hap- 
pened during the development of 
CYLINDRIX, but the effect was so pro- 
found that it had a direct impact on 
DEAD RECKONING. Also, during the 
development of DEAD RECKONING, I was 
able to fix the mistakes made during 
CYLINDRIX (not that I didn’t make all 
new mistakes during DEAD). But 
because couldn’t fix this problem, I 
have to mention it here. 
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As developers, many of us may feel 
we lack the acumen needed to deal 
with publishers, employees, and other 
business situations, apart from the 
technical and creative. Many years 
ago, I attempted to balance this (per- 
ceived) weakness of mine and hired a 
consultant. There were bad decisions 
set in motion during the very begin- 
ning of CYLINDRIX that affected the 
development of DEAD RECKONING 
many years later. This was due mainly 
to the restricted cash flow caused by 
the debt incurred during the develop- 
ment of CYLINDRIX. 

In hindsight, I realize that all I 
lacked at the time was the self-confi- 
dence to handle these decisions and 
situations that initially frightened me. 
When all this well-meaning advice was 
being enacted, I was deeply conflicted. 
My instincts screamed that things 
weren't right, but I didn’t follow my 
conscience. Of course, when all the 
bad effects of those decisions started 
surfacing towards the end of develop- 
ment, I was forced to handle ten times 
what I would have had before hiring 
the professional. 

The problem is that most business- 
men don’t understand the computer 
games marketplace, and fewer under- 
stand the game developer. Having a 
“suit” show up in my office and do the 
back-slapping, hand-shaking, and 
other customary behaviors that seem 
so insincere (to most people) served 
only to make the team very uncom- 
fortable. I found out later it made 
them all downright suspicious and I 
don’t blame them. 

I was also advised to maintain a 
“proper” office with a receptionist and 
several management functions. They 
were expensive and unneeded in a 
game development environment, and 
overkill that only served to sap devel- 
opment resources. What is defined as a 
proper office in one profession is all 
wrong in another. 

The end of my consultant phase was 
when I was pushed to self-publish 
CYLINDRIX. This desire was based on 
the greed factor and not the facts. To 
make a long story short, six figures of 
advertising alone will not get your 
game anywhere near a retail shelf. You 
need a publisher. 

But when I did decide to get a pub- 
lisher, we overestimated drastically the 
title’s worth. Because the price was so 
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far off base, we obviously didn’t get a 
deal. Finally, | went solo and turned 
my efforts to trying to find a publisher 
for CYLINDRIX at reasonable terms and 
cut my losses. By this time, CYLINDRIX 
was very dated and all the ads that had 
run turned off potential publishers. 
They wanted to launch it themselves 
and didn’t want to try to compete with 
all the marketing and publicity already 
generated. The publisher I finally went 
with turned around and sublicensed 
the game into obscurity. 

But CYLINDRIX was not a failure, 
because it didn’t end there. We took all 
that we learned and used it to create 
DEAD RECKONING. The fact that 
CYLINDRIX was a great game and was 
well-known for that period of time also 
allowed us to get the publishing deal 
with Piranha. 


In the End... 


uring the development of DEAD 

RECKONING, I’ve had some lofty 
highs and dismal lows, and the design 
document kept me focused. Drift got 
bad for awhile; then I dusted off the 
design document and got back on 
track. And despite the effectiveness of 
the design document, there are a thou- 
sand things I’m doing differently this 
time around. It is most exhilarating to 
see a vision fulfilled and know the next 





one will be even grander. @ 
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ENTERTAINMENT 


SO DO WE! 


CAN YOU PROGRAM A 
TOP TITLE? 


WOULD YOU LIKE 
A SHARE OF THE 
PROFIT? 


WANT TO SET 
YOUR HOURS? 


| WELL? WHAT ARE 
} YOU WAITING FOR? 


WRBANK, CALIFORNIA { 
jog Programmers need not apply.) @ | 


ATTERS@TREMOR.NET 


Our Projects: 


Racing (PSX, N64 & PC)-Stormfront’s NASCAR ’98, published by EA 
Sports, was one of the top hits of 1997 and 1998. Now we want to take 
it farther. 


You Don’t Know Jack (PSX)-A technically challenging project, big 
market potential, with an emphasis on exquisite comic timing. 


Fantasy Role-Playing (PC)-A top license and a top publisher, featuring 
key innovations in game play. We’re building a new engine from 
scratch. 


Baseball (Consoles and PC)-Hot technology, exciting game play and 
graphic flair. Major publisher, chance to be a smash hit. 


Soccer Game for Girls (PC, Mac)-The first in the line, “Starfire Soccer 
Challenge,” got great press and will be out this fall. For Purple Moon. 


We're adding to our award-winning staff of 70 and looking for a 
Technical Director and Programming (PSX, N64 & PC) and Art talent. 
You must be able to prove that you can play an integral role in creating 
the next generation of blockbuster game titles. 


Please send your resume to: 


Stormfront Studios, Attn: M. Daglow, 4040 Civic Center Drive 
San Rafael, CA 94903 Fax: 415-461-3865, E-mail: mdaglow@aol.com 
www.stormfrontstudios.com 


San Diego based Angel Studios is 
Koto) ale Wi fo) m—y.< el-1g[-1alei-10 fm 8)-10)6](- me) 
cro) F-lolele-(-Melamere) tirave) -\0 o (Nom 
PC, Arcade and LBE creations. 
a Wanna play? 


— 3D/2D Artists - 3DS 
MAX, Photoshop, 
real-time 


We’re not just playin’ games! 


Programmers - C++, 
graphics, physics 


Game Designers - 
‘CF Taat- mere) alice) Mamer- lance 
era tuning, writing, 
real time 3D a plus 


Producers 


Motion Capture 
ai=ceislalietctars 


er information: AWA ers] ale [=] Px@ce) an) 
hr@angel.com / 760-929-0719 fax 


Please note that you heard about us through Game Developer 


VISIT OUR WEB SITE AT : 


www.Digitalanvil.com 


Digital Anvilis a multimedia entertainment software company 
born out or the talents of Chris Roberts, creator of the top selling 
Wing Commander series, a top creative team from the software 
and film industries and the resources of Microsoft. Digital Anvil 
was formed to create innovative games and movies with high 
impact Storylines and mass audience appeal. We al 
looking for creative men and women who share our vis 
{he potential interactive entertainment. | 


Artist 
PLOLTammersrs 
DCSISMETS 


Send resumes to: careers @digitalanvil.com or fax to the attention 
of Evan Brandt (512) 457 - 0404 www.digitalanvil.com/low/jobs 
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GameFX Inc. 3 

35 Hartwell Ave. mae 
Lexington, MA02173 ¢ = 
or Email: Andrew@GamePeeom 
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everybody wants to rule the world... 

not everyone has a chance 
to do it... 
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PAVILION 


DIGITAL MEDIA CENTRE 


> 16 Week Full-Time 


3D Digital Animation Training 


> Softimage/Maya/Houdini 
> Motion Capture 
> Starts February & June 1999 


Seneca College of Applied Arts & Technology 
Tel: (416) 491-5050 ext 4445 


Toronto, Canada ger > ; 
Silicon *;44 Graphics 
http://dmc.senecac.on.ca dmc@senecac.on.ca |  balaasiz Sites 


*OSAP loan eligible 
Model by student; 
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Enlist in a five day, 
hands-on SD ‘98 
Bootcamp and learn how 
ate | mm to build powerful and — 
flexible programs with 
COM and DCOM. 


Seminars in Building COM/DCOM Components 

with Visual C++, MFC and ATL. : 
. )\\ EXPERT 

INSTRUCTOR: 


TEAM Discount! 
Register 5 more people at 


A the full price and the 6th 


person attends FREE! All reg- 


: Se _ . istrants also receive a free SD J ‘ CNnCmD | 
collectors t-shirt! Pricing an. g 
r \ available at our website or . 
call for a brochure! A a is 
5 Days of Intensive Hands-On Training | | | eh) 


SUTICHEUNG. 
Seattle Oct 5—9 a ii 


me | Ot 1 Ce 1-800-OK-ACURIS .- 1-800-652-2874 
Arlington, VA Nov 9—13 


www.acuris.com | e-mail: stevem@thelab.net 
Boston Nov 16—20 SD) 5 
So 2 


Atlanta Nov 30—Dec 4 


DEVELOPMENT 
Contact us today! www.sdexpo.com/1998/bootcamp 


800-441-8826 ¥ 415-905-2702 & bootcamp@mfi.com Miller Freeman 


Dear Game Developer, 





If you’re technically astute and have a way with words, 
Game Developer magazine needs you. We’re looking for 
feature articles on graphics programming, testing and QA, 
producer/management issues, audio, art and animation, 
internet game development, new technologies, and game 
design. We’re also looking for people to review game 
development tools. 





Please send your abstract or outline to: 
adunne@compuserve.com 


Writer’s guidelines can be downloaded from our web site at: 
http: //www.gdmag.com/writguid. htm 


di Ds . 


Editor in Chief g C CT oy 





When’s the last time you performed an 
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LESSONS FROM THE NEXT GEL: 


ToOlS& 2 
TECHNIQUES 
FOR INTERACTIVE: 
AUDIO | 


DATA 
STRUCTURE | 
DESIGN 









CREATING AN IMMERSIVE 
SOUND WORLD 


DAVE THIELEN'S PARTING 
SWOT FROM THE SOAPBOX 


We do them 


every month at 
Game Developer. 


Our POSTMORTEM column 
dissects the development of 
“A” titles like Bungie’s MYTH, 
Westwood’s BLADE RUNNER, and 
Microsoft’s AGE OF EMPIRES— 
from the point of view of the 


programmers, producers, 
animators and sound professionals 
who created them. 

If you’re part of a team that 


develops games, you should read 
Game Developer. 


We also cover: 
¢ audio 
¢ programming 
¢ News 
- art & animation 
¢ new products 
¢ quality assurance 
& production 
¢ hardware 
¢ industry opinions 
e and oh, so much more 


If you qualify, subscription in 


FREE. 


Just fill out the subscription card in this 
issue and send it in. 


Or aubacribe online at 

www. synansoft.com/hallmark/gd/ 
Back issuer at : 

www. gdmag.com/backias. htm/ 





Ul Miller Freeman 







































You’ve got a game in 
production and you're 
building the tools for the 
next one BUSS: 
for playin’ around. 





Get serious with 
industrial-strength 

tools from the Factory — 
CodeWarrior Professional 
and CodeWarrior for 
Playstation. 


Here’s why more than 
100,000 programmers 
are dead serious about 
CodeWarrior: 


= Cross targets: 

game consoles, 

PC, and Macintosh 
Wickedly fast 

build times 
Easy-to-use GUI 
interface 
State-of-the-art 
graphical debugger 
= Support for AMD-3D™ 
technology 














www.metrowerks.com 


1-800-377-5416 
info@metrowerks.com metrowerks 
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The Best in Game Development Technology! 





Introducing Bink - the new true-color codec from the author of Smacker! 

Jeff's done it again! Bink is now available and revolutionizing game videos just like Smacker did four years ago! Bink is a 
“better-than-MPEG-II” class codec. Yup, that’s right - better than DVD! It produces higher-quality than MPEG II and is up to 
three times faster than other software decoders. Now there is finally a true-color codec good enough for game developers. 


Bink is a hybrid block-transform and wavelet codec that can encode your video using 16 different compression techniques 
af (142 wavelet, DCT, motion compensation, a variety of vector quantizers, Smacker-style, etc). With all of these techniques in 
Vi D = Oo one codec, Bink can handle almost any type of video. Bink also includes a psycho-acoustic based audio codec that is 


capable of 8 to 1 perceptibly lossless compression, so your audio will sound as good as your video looks. 


Bink is available now for Windows 95/NT (DOS and MacOS coming soon) and supports DirectDraw, DIBSections, DirectSound, and the Windows 
waveOut system. Bink uses the YUV colorspace, so it can use DirectDraw overlays for hardware color conversion and smooth scaling. Bink also 
includes a bunch of hand-optimized assembly YUV to RGB colorspace blitters, so you'll be able to access Bink’s Output in any RGB format you like. Bink 
is a high-end codec, and as such, it requires at least a Pentium/150 (Pentium/200 preferred). Bink really doesn't have a minimum CD requirement - 
320x240 animations look great at 150 kps (1x CD) and 640x480’s only need 450 kps (3x CD). Bink does need a reasonable video card that is capable 
of handling all the true-color pixels, though. The Bink SDK is very similiar to Smacker's, so integration is easy, and upgrading from Smacker is easier still. 


Youre really going to love Bink - download the Bink Tools (or call for a demo CD) and try it on your videos today! 


New MPEG Layer-3 decompression support! 

Miles 5.0 includes a redistributable MPEG Layer-3 decoder (patent rights licensed from Thomson and Fraunhofer). MP3 
provides perceptually lossless compression at 11 to 1! Your sound files will be more than ten times smaller and will sound 
exactly the same! Miles supports both on-the-fly decompression (for minimal memory use), or pre-playback decompression 
(for minimal CPU hit). Miles even supports MP3 compression of DLS instrument data for incredibly small MIDI files. 


New high-level 3D sound support! 

Miles 5.0 has an all new high4level 3D sound API which supports DirectSound3D, Intel’s RSX, Creative’s EAX, and Aureal’s A3D 
SOUND SYSTEM (selectable at run-time). With Miles, you can have 3D audio in your game in minutes! More importantly, you won't be tied to 

a specific low-level 3D API, so you can use the technology that makes your game sound best. 


All new digital sub-system! Faster mixing, filtering, and plug-in support! Replaces the DirectSound mixer! 

Miles 5.0 includes a completely new digital audio subsystem. It includes an even-faster mixer (with MMX support), on-the-fly filtering, and a new plug-in 
system for adding run-time sound effect processors which can be called at the pre- or post-mix stage. Miles also now uses its own mixer even when running 
under DirectSound - if your game starts and stops multiple sound effects frequently, then this new feature can potentially double your frame rate! 


Of course, Miles 5.0 provides all of the features you loved in earlier versions: complete digital mixing, interactive MIDI playback with a built-in DLS software 
synthesizer, hard drive or CD-ROM digital streaming, red book CD-audio support, powerful callbacks, and much more! 


Smacker - the best 256-color codec on the planet! 

Yes, Smacker is still available! Smacker is still the best codec for situations such as: 256 color games (of Course), games 
targeting low-end machines (Pentium 133 and below), games that need video sprites or video transparency (which is 
much faster in 256 colors), cell-based (cartoon-style) videos, animated 3D texture compression, and very high-resolution 
videos (800x600 or 1024x768 - only Smacker is fast enough for videos this big). 


The Smacker SDK is available for DOS, 16-bit Windows, Windows 95/NT, Win32s, 68K Mac, and PowerMac. The SDK’s 
API is identical across these platforms, and Smacker files can be played without conversion on each platform. 


Ssmacker supports DirectDraw, DIBSections, WinG, DispDIB, SVGA VESA, and GWorlds (MacOS) for graphics output. For sound output, Smacker 
supports the Miles Sound System, DirectSound, the Windows waveOut system, and the Sound Manager (MacOS). 





_ Who's using RAD? Everyone! Here's a partial list of our customers: 
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